We are an eMembership publication and naturally know our own platform best. This guide is written to be useful to any union leader evaluating cloud software on security grounds, regardless of which vendor they choose. It draws on federal labor law, Department of Labor compliance guidance, published audit standards, and vendor documentation. The eMembership-specific material is walled off in a single section near the end.

What union data security actually covers

Union data security is the set of technical and administrative controls that protect a labor union's member, financial, and case records from unauthorized access, alteration, or loss. Compliance is a separate question. It asks whether the union can demonstrate, to a regulator or an arbitrator or its own members, that it met a specific legal duty.

The two get blended in vendor marketing, and the blending causes real problems. A platform can be well engineered and still leave a local out of compliance, because parts of the duty are procedural rather than technical. A local can also be fully compliant on paper and still be one reused password away from an incident.

Keeping them separate produces a cleaner buying question. Security asks: can someone who should not have this data get it? Compliance asks: when someone who is entitled to this data asks for it, can we produce it, prove it is complete, and show who touched it?

Most vendor security pages answer the first question at length and the second not at all. That gap is the reason this guide spends as much space on record duties as on encryption.

What is inside a union database, and why the mix is unusual

Corporate software vendors talk about customer data as though it were one substance. A union database is not one substance. Look at what accumulates in a mature membership system:

• Personal identifiers, including names, home addresses, phone numbers, dates of hire, and in many implementations Social Security numbers.
• Financial records: dues history, payment methods, employer remittances, delinquency status, and account balances.
• Grievance files, which routinely contain discipline records, medical details, pay information, and correspondence with counsel.
• Political contribution data, since COPE authorization details and opt-out windows are tracked per member.
• Organizing assessments, meaning documented judgments about which workers at which sites support the union and how strongly.
• Voting and survey participation, including ratification ballots and officer elections.

The last two items are what make union data different from association data. An organizing assessment list is, functionally, a document identifying supporters at a worksite. A ratification roll is a record of how a bargaining unit voted. Neither has a clean analogue in a trade association's CRM, and neither is well served by security thinking imported from generic membership software.

This also explains why several regimes can apply to one local at once. A union administering a health or welfare benefit fund may sit inside HIPAA's reach. A union collecting card payments touches PCI DSS. Every union filing LM reports is inside the LMRDA's recordkeeping rules. And any union holding Social Security numbers has breach notification duties under state law, since all fifty states have breach notification statutes on the books, along with the District of Columbia and the territories.

The certification vocabulary, decoded

Vendors list acronyms. Buyers rarely get told what they mean, which turns a security evaluation into logo counting. Here is what each one actually asserts.

SOC 1

A SOC 1 report covers controls relevant to a client's financial reporting. In the United States it is performed under the AICPA attestation standards, specifically AT-C section 320, which SSAE No. 18 introduced and which is still the governing section. The international analogue is ISAE 3402. If a vendor's report cites SSAE 16, that standard was superseded in 2017. For a union, SOC 1 is the report that matters when the vendor's system is part of how dues, remittances, and disbursements get recorded, because a union's auditor may need to rely on it.

SOC 2

A SOC 2 report is issued against the AICPA's Trust Services Criteria. Security is the mandatory category. Availability, processing integrity, confidentiality, and privacy are selected based on what the vendor commits to, which means two SOC 2 reports can cover meaningfully different ground.

This is where the type distinction lives, and it is the single most useful question in a security evaluation. A Type I report assesses whether controls were suitably designed as of one specific date. A Type II report assesses whether those controls were designed correctly and operated effectively across a defined observation period, commonly three to twelve months. Both types also opine on whether management's description of the system is fair, which is worth reading on its own. Type II reports include the auditor's test procedures and results. Type I reports do not.

Ask which type. If the answer is Type I, that is not disqualifying, but it changes what you know. Ask when the observation period closed, too. There is no rule that a SOC report expires. In practice buyers and their auditors treat one as current for about twelve months, a convention the AICPA reinforces by licensing its SOC logo for only twelve months from the report date. A two-year-old report describes a company that may no longer exist in that form. Expect a gap between the end of the observation period and the day you are reading, and expect the vendor to cover it with a bridge letter. Know what that is: a bridge letter is signed by the vendor's own management, not by the auditor, and the AICPA sets no standard for its contents. It is a representation, not assurance.

ISO 27001

ISO 27001 certifies an information security management system, meaning the governance apparatus around security rather than a fixed list of technical controls. It is an international standard with a certification body behind it, so unlike a SOC report there is an actual certificate. Its value to a buyer is that it evidences ongoing management review, risk assessment, and corrective action rather than a snapshot. Two things to check on the certificate itself. The version: the current standard is ISO/IEC 27001:2022, and the transition window from the 2013 edition closed on 31 October 2025, so a certificate citing ISO/IEC 27001:2013 has lapsed. And the scope, because an ISO certificate covers a defined scope that may not include the system serving you. Verify it through the certification body's public register rather than accepting a PDF.

HIPAA

HIPAA is where the vocabulary gets loose. The Department of Health and Human Services does not issue HIPAA certificates, so "HIPAA compliant" describes a vendor's assessment of its own conformance with the Security Rule safeguards, usually validated by an independent assessor. That does not make the claim empty. It does mean the follow-up question matters more than the claim: if your local administers a benefit fund, will the vendor execute a business associate agreement, and what does that agreement say about breach notification timelines? Get the entity right as well. A union health and welfare fund, including a multiemployer Taft-Hartley fund, is a health plan and therefore the covered entity. The local acting as plan sponsor is not. The agreement is with the fund and is signed by its trustees or their delegate, not by the local.

PCI DSS

PCI DSS is the payment card industry's standard for handling cardholder data. Check the version and the artifact. Version 4.0.1, published in June 2024, is the only active version: v3.2.1 retired on 31 March 2024 and v4.0 retired on 31 December 2024. The requirements v4.0 designated as best practices until 31 March 2025 are now mandatory, so every requirement is in scope for any assessment done today. A Report on Compliance completed by a Qualified Security Assessor is also a different level of evidence than a Self-Assessment Questionnaire, and the Attestation of Compliance tells you which one you are looking at. For unions collecting dues by card, the useful insight is counterintuitive. The strongest position is not a vendor with impressive card-handling controls. It is a vendor that never stores card numbers at all, routing payment through a certified processor so the card data never lands in the membership database. Ask directly whether card numbers are stored anywhere in the platform.

The scope test

Run these three questions against any certification claim, from any vendor, before it counts as evidence:

A vendor that answers all three without hesitation is telling you something about its security program beyond the answers themselves.

The Union Data Protection Stack: a buyer's framework

Security checklists tend to be long, undifferentiated, and impossible to weigh. The framework below organizes the evaluation into five layers, ordered from the foundation upward. Score any platform against each layer. The point of the ordering is that a weakness at a lower layer cannot be fixed by strength at a higher one, and that the layers are not owned by the same party.

Layer 1: Facility and infrastructure

Where the data physically sits and who is responsible for the hardware it sits on.

Ask: who owns the servers, and who patches the operating systems? Is the facility staffed around the clock, or is it a rack in a colocation cage that someone drives to? Are power, networking, cooling, and internet connectivity redundant? What happens on a hardware failure, and is recovery included or billed?

The weak answer to watch for is a vendor that names a large cloud provider and stops there. Running on certified infrastructure is a real advantage. It is not the same as the vendor having its own controls audited, and the distinction is worth pressing on.

Layer 2: Transmission and storage

What protects the data in motion and at rest.

Ask: is all traffic encrypted in transit with current TLS? What specifically is encrypted at rest, and at what level, since disk-level encryption and field-level encryption defend against different attacks? Are backups encrypted, and are they held somewhere other than the primary facility? Are card numbers stored at all?

Encryption at rest protects against the theft of a disk or a backup tape. It does nothing about a staff account that should have been deactivated eight months ago. Which brings you to the layer where most of the real risk lives.

Layer 3: Identity and access

Who can get in, what they can see once they are in, and how quickly access ends.

Ask: is multi-factor authentication available, and can the union enforce it rather than merely offer it? Does every user have a unique ID, or does the office share a login? Are sessions timed out? Can access be scoped by role so that a steward sees their own caseload and not the whole local's grievance files? Can a member see their own record and nothing else?

Then ask the question that is specific to labor organizations and almost never appears on a vendor checklist: what is the process when an officer loses an election?

Union staffing turns over on a schedule set by elections and volunteer availability rather than by HR. Stewards rotate. Trustees change with an administration. A corporate deprovisioning process assumes a manager files a ticket when someone resigns. A union needs a process that fires when a term ends, and that process belongs to the union, not the vendor.

Layer 4: Record integrity and evidence

Whether the system can prove what happened to a record.

Ask: does the platform log who changed what and when? Can you produce a complete history for a member, a grievance, or a dues transaction on demand? Does history survive after a case closes or a member leaves? Can records be located and retrieved by an indexed identifier rather than by hunting? Can they be exported in a form that stays legible outside the system?

This layer is where security and compliance meet, because an audit trail is a security control and a legal exhibit at the same time.

Layer 5: Governance and continuity

The program around the controls, and what happens when something fails.

Ask: is there a written, management-approved information security policy? How often are formal risk assessments run? Is there a documented incident response program that covers privacy events as well as security events, and what are the notification timelines in your contract? Are business continuity and disaster recovery plans tested, or only written? Does the vendor run penetration testing and vulnerability scanning, and who performs it? Do employees complete security awareness training on a recurring basis? Who are the vendor's own subprocessors, and were you told about them?

Reading the stack

The layers are not evenly divided between the parties. Layers one and two are almost entirely the vendor's to deliver and yours to verify. Layer three is genuinely shared, and the union's half of it is configuration and discipline rather than software. Layers four and five are shared as well, but the union's half of those is the half that never gets scored in a demo, because nobody demos a records retention policy.

A useful test: if your vendor were acquired tomorrow and the account team turned over completely, which of these five layers would still hold? The ones that would are the ones you own.

The compliance duties that do not transfer to your vendor

This section is the one that most union software security content skips entirely, and it is where a local is most likely to get hurt.

LMRDA recordkeeping

Under the LMRDA, every filer must maintain the records that allow its reports to OLMS to be verified, explained, or clarified, and must keep those records available for examination for not less than five years after the filing of the documents based on the information they contain. Note where that clock starts. It runs from the filing date, not from the date of the record, so a receipt is retained well past five years from the transaction. Some records must be kept longer if they remain necessary to verify a filing inside that window. Election records carry their own separate rule with a much shorter clock. Section 401(e) requires the designated election officials, or the secretary if none is designated, to preserve the ballots and all other records pertaining to the election for one year, and section 401(f) imposes the parallel duty for officers chosen by convention. OLMS's regulation at 29 CFR 452.106 reads the year as running from the election and adds three points to check against any system you buy: all ballots must be kept, marked or unmarked; voided ballots must be kept too, including those rejected as late or cast for an ineligible candidate; and independent certification as to the number and kind of ballots destroyed may not be substituted for preservation. A vendor offering you an audit log of destroyed ballots has not met that requirement.

Those obligations attach to the union. Not to the software.

Electronic storage, and the contract clause nobody reads

OLMS has published guidance on electronic recordkeeping that sets out what a union's electronic storage system has to do before paper originals can be destroyed. Note the date on it: the compliance tip was last updated in February 2011, so it predates essentially every cloud platform you are evaluating, and it is still OLMS's current published guidance. The system must preserve and retrieve records, maintain their integrity and legibility, prevent and detect unauthorized creation, alteration, or deletion, and include an indexing system that permits identification and retrieval. The union must be able to hand OLMS a complete description of the system, including its indexing procedures, on request.

Then comes the sentence that belongs in every union software procurement conversation and appears in almost none of them. OLMS states that the electronic storage system must not be subject, in whole or in part, to any agreement that would limit or restrict OLMS’ access to the stored records.

Read your cloud contract against that. What happens to your data during a billing dispute? Can the vendor suspend access for nonpayment? What is the export window at termination, and in what format? If a vendor can lock your local out of its own dues ledger for thirty days, that is a commercial risk and also a live question about whether your storage arrangement satisfies the recordkeeping rule.

Electronic voting

Unions running officer elections electronically are working inside specific federal guidance. OLMS has issued a compliance tip explaining how the LMRDA's requirements apply to remote electronic voting systems, and it is worth reading in full before any vendor conversation. A summary of what it says, which is not a substitute for reading it:

The LMRDA requires secret ballots, adequate safeguards to ensure a fair election including the right of a candidate to have an observer, and preservation of election records for one year. OLMS evaluates each system case by case rather than certifying any product, and the guidance explicitly offers no safe harbor.

On ballot secrecy, OLMS lists protections it would view favorably. These include allowing members to vote only through a secure portal such as one using multi-factor authentication, randomizing the order in which votes are stored so the tally reveals nothing about sequence, storing returned ballots in encrypted files openable only through multiple decryption keys distributed among a diverse group including representatives of competing candidates, logging attempts to breach those files, and using technology that prevents ballot image capture.

On observer rights, OLMS acknowledges that an observer cannot watch an internet election the way they watch a ballot box, and identifies indirect methods it would accept, including inspection of open source code at the observer's own cost or a certified audit by a reputable third party.

On the right to vote, there is a requirement that catches unions off guard: a union-provided access point or an alternative voting method must be made available on request to any member who does not have internet access, and the implementation must not create barriers for members with accessibility needs. That is a planning obligation, not a software feature.

GDPR, and whether it applies to your local

GDPR turns up in union software keyword searches constantly, and for most locals it is answering a question they do not have.

The regulation's territorial scope is set by Article 3. It reaches organizations established in the EU, and it reaches organizations outside the EU where the processing relates to offering goods or services to people in the EU, or to monitoring their behavior within the EU. A local in Ohio representing members who work in the United States is generally outside that scope, and a vendor's "GDPR ready" badge tells such a local very little about how well its data is protected. A Canadian component is a different legal question, not a GDPR one. Alberta's Personal Information Protection Act names trade unions expressly among the organizations it covers, it reaches employee personal information as well as member data, and it carries mandatory breach reporting to the provincial Information and Privacy Commissioner. The federal PIPEDA can still apply where personal information crosses provincial or national borders, which is exactly what a US-hosted vendor does with Canadian records.

Where it does become a live question is narrower and worth flagging: an international with affiliated bodies in Europe, a local with members stationed in the EU, or a union whose website deliberately targets people in the EU. If any of that describes your organization, this is a question for counsel rather than for a vendor's marketing page.

The general principle holds beyond GDPR. A privacy regime is not a security rating. Treat a compliance claim as evidence about a specific legal question and nothing more.

Electronic signatures

Unions increasingly collect dues deduction authorizations, membership applications, and COPE authorizations electronically. The legal weight of those signatures under federal and state electronic signature law depends less on the visual signature than on the record of the signing process: what the signer was shown, when, from what device, and whether the signed document and the audit record stay linked afterward.

If a signed authorization is ever challenged, the question is whether you can reconstruct that. Ask any vendor what the audit record for a signature actually contains and how long it is retained.

How to run a union data security evaluation

Start with your own data, not with a vendor's security page.

• Inventory what you actually hold. Walk your current records and write down which categories exist: Social Security numbers, medical information inside grievance files, benefit fund data, card payment data, organizing assessments, election records. That inventory determines which regimes apply to you, and it is the document every subsequent question hangs from. Most locals have never written it down.
• Ask for reports, not badges. Request the actual SOC report under NDA. Run the scope test on it. If a vendor cannot produce a report and cannot say why, that should be a red flag.
• Score the vendor on layers one and two, and score yourself on three, four, and five. The second half of that exercise is uncomfortable and is the reason it gets skipped. It is also where a local finds out that its office shares a login.
• Read the contract for the things security pages never mention. Who owns the data? What the export path is at termination and in what format. What the breach notification timeline is and who notifies members. Whether access can be suspended, and under what conditions. Whether any clause could restrict a regulator's access to your records.
• Ask about the boring operational questions. How does an account get deactivated when a term ends? How are new staff granted access, and by whom? Is MFA enforced or optional? When was the last penetration test, and did anything material come out of it?
• Check references on incidents, not on features. Ask an existing client whether they have ever had a security question, how the vendor responded, and how long it took. Vendors are consistent about features and revealing about incidents.

What most unions get wrong

The first mistake is treating a certification list as the answer. A row of acronyms is a starting point for a conversation, and buyers routinely treat it as the conclusion of one. The scope test takes four minutes and separates vendors far more effectively than the logos do.

The second mistake is assuming compliance moved along with the data. This is the most consequential one. When a local moves from a filing cabinet and into a cloud platform, it feels like the recordkeeping problem has been handed to somebody else. It has not. The LMRDA duty sits with the union, the OLMS access requirement constrains what the union may agree to in a contract, and the election records rule applies whether the ballots were paper or encrypted files. A union that understands this reads its software contract differently.

The third mistake is buying controls that nobody turns on. Multi-factor authentication available is not multi-factor authentication enforced. Role-based access, configured once at go-live and never revisited, can quickly become a system where, in a little over three cycles, a dozen people can see grievance files that they have no business seeing. The gap between a platform's security capability and a union's security posture is closed by administrative habit, and nothing in a procurement process creates that habit.

How eMembership approaches union data security

This section is about our own platform. Everything above applies regardless of which vendor a union chooses.

eMembership runs on infrastructure that Winmill owns and operates rather than resells. Measured against the five layers in this guide, here is what that means.

On facility and infrastructure, Winmill owns the server hardware, handles operating system upgrades and security patching, and staffs the facility around the clock. Power, networking, environmental controls, and internet connectivity are redundant, and recovery from hardware failure is included in the subscription rather than billed. Now apply this guide's own scope test to us, which is the only honest thing to do in an article like this one. eMembership runs inside a SOC 1 (SSAE 18) and SOC 2 audited, ISO 27001 certified facility. Those audits and that certificate belong to the facility. That is exactly the distinction this guide has been arguing you should insist on. The facility's reports reach Winmill under a non-disclosure agreement, so we are not able to forward them, which is standard for colocation. If your evaluation requires a report you can read for yourself, raise it early and we will tell you plainly what we can and cannot provide.

On the other two standards, be precise about what they are. Winmill maintains HIPAA Security Rule compliance for the eMembership environment, supported by formal annual risk assessments. That covers the Security Rule safeguards rather than the Privacy Rule or the EDI transaction standards, and the distinction matters if your local administers a benefit fund. eMembership is PCI DSS compliant, and card numbers are never stored in eMembership at all because processing runs through certified third-party processors, which is the position described earlier as the strongest available on the card question. On transmission and storage, our data is encrypted in transit using TLS, and sensitive member data, including Social Security numbers, is encrypted at rest using disk-level encryption. Nightly backups are encrypted and transmitted offsite.

On identity and access, multi-factor authentication is available to every union on the platform. Access is granted on a least-privilege basis with unique user IDs and enforced session timeouts. Role-based views scope what each person sees, and in the member portal members see only their own information. The deprovisioning discipline described above remains the union's to run, and it is worth raising during implementation rather than after.

On record integrity, grievance records are timestamped and auditable at every step, and closed cases stay searchable. Documents signed through electronic signatures are stored on the member's profile along with the data captured during signing. Member reports and queries export to CSV, which matters for the retrieval and legibility expectations in the OLMS electronic recordkeeping guidance.

On governance and continuity, Winmill maintains a management-approved information security policy, conducts formal risk assessments at least annually, performs both dynamic and static code scanning alongside code reviews, and tests business continuity and disaster recovery plans through regular exercises. Winmill's own cybersecurity practice runs penetration tests against the eMembership environment on a recurring basis, with findings triaged and remediated through a defined process. For the sake of the distinction this guide has been drawing: that team is internal to Winmill, not an outside firm. Employees complete security awareness training at hire and annually. Physical access to the facility is reviewed every six months. Security operations are overseen by a Director holding CISSP and CISA certifications. Full detail sits on the security and data center page.

On voting specifically, eMembership's electronic voting is built to comply with the LMRDA and the OLMS guidance on remote electronic voting, including ballot secrecy, observer rights, and record preservation, with anonymous mode as the required configuration for formal votes such as ratification ballots, officer elections, and strike authorizations. Details are on the surveys and votes page. As that page notes, and as this guide has argued at length, confirm any specific compliance question about your own union's situation with your own legal counsel. SEIU Local 500 ran a contract ratification reaching 20,000 members through the platform, which speaks to scale rather than to a security outcome.

Which modules a union runs, and therefore which of this applies to which records, is determined through the Discovery Process rather than through a fixed package. The Member Web Portal and the Member Mobile App are separate additions to a subscription. Security controls described here are part of the standard environment for every union on the platform.

Whether eMembership is the right fit depends on a local's size, structure, and how much it values having its records inside a single managed environment rather than spread across separate tools. A union that wants to answer a member's question about who accessed their record without assembling the answer from three vendors is the kind of union this tends to suit.