Compliance obligations get discussed as one category. Somebody says they need to be compliant, somebody asks which framework, and back comes a list with a law, an audit report and a certificate side by side as if they were one thing.
Usually that list arrives in a security questionnaire or halfway through a procurement call, and usually it arrives with the word compliant doing all the work. HIPAA, SOC 2, ISO 17025, Part 11. Four items, one adjective, and the adjective means something different in every case. Nobody is being careless. The vocabulary genuinely runs together, and most vendors have an interest in leaving it that way.
The cost of leaving it there shows up late. A different party decides each obligation, each one wants different evidence, and each arrives on its own timetable. So a team can prepare carefully for the wrong shape and only discover it in month nine, when somebody asks for proof that a control operated all year and the records begin the week the project started.
Taking the three apart costs almost nothing. It is the step most often skipped, and the only one that makes the others answerable.
What are your compliance obligations, exactly?
Three shapes: a law, an attestation or an accreditation. Most organizations face more than one at a time, which is how they blur together, and taking them apart tells you what your system has to produce.
The quickest way to sort them is to ask who decides. The answer differs in all three cases, and it governs everything that follows: who you deal with, what they accept as proof, and whether you end up holding a document at all.
- A law applies whether anybody ever looks or not. Nobody declares that you have met it, and there is nothing to hold at the end of it. HIPAA works this way in the United States, and so does GDPR in Europe, and so does 21 CFR Part 11 for electronic records in regulated manufacturing.
- An attestation is what somebody writes about you after examining you. You engage them, they examine, and you finish with a report that carries findings and covers a stated period. SOC 2 is the one most people mean, and SOC 1 does the same job for controls over financial reporting.
- An accreditation is what a standards body grants against its own standard. You apply, they assess, and you finish with a certificate that carries a scope and usually an expiry date. ISO 17025 works this way for testing laboratories, and ISO 9001 for quality management systems.
One organization can easily face all three at once. A law binds a testing laboratory whatever it does, it may hold an accreditation because its customers expect one, and a customer auditing its own suppliers may ask it for an attestation. Three obligations, three different parties, and no overlap in what any of them accepts as proof.
Which is why the useful question is not whether you are compliant. It is which of the three you are answering to, and what that one will ask you to produce.
Is HIPAA a law or a certification?
A law, and there is no HIPAA certification. It binds you because of what you handle rather than because you signed up, and nobody schedules an inspection. The HHS Security Rule is where the requirements live.
The counterintuitive part is that nobody issues a HIPAA certificate. So a product calling itself HIPAA certified is describing something that does not exist. What exists instead is an arrangement: both parties sign a Business Associate Agreement before anybody handles protected health information, the platform runs on HIPAA compliant AWS infrastructure, and access reaches down to the individual field. Our HIPAA database software page has the detail, and our HIPAA database best practices post covers the operational side.
So with a law the question is never where the certificate is. It is whether you could show what happened years later, about one record.
Is SOC 2 a certification?
No. It is a report an auditor writes about an organization after examining it against the Trust Services Criteria, either for a point in time or across a period. The AICPA publishes the framework, and is worth reading over any vendor summary.
Two things follow, and both get missed. Because it is a report rather than a certificate, there is no pass mark and no badge. And it describes the organization examined, so your own report covers you rather than the software you run. Your auditor looks at your vendors while examining you, but their controls reach your report through your vendor management, not theirs.
The practical consequence is that an attestation asks you for evidence about how you operate, continuously, across the period under examination. Not a snapshot taken the week before.
What is an accreditation, and who grants it?
A standards body grants it against its own published standard, usually after a visit.
Laboratories know it well. ISO/IEC 17025 works this way, and our overview of it covers the practical side. Note that 21 CFR Part 11 is not an accreditation despite behaving like one in practice: it is a regulation, enforced by inspection rather than certified by a body, which our Part 11 checklist covers. Accreditation tends to be the most prescriptive of the three, because the standard says what you must do rather than leaving you to show that your own controls work. So what it asks for is specific: named procedures, named responsibilities, and records in a particular form.
What evidence do compliance obligations want?
A law wants one record's history years later. An attestation wants proof that controls operated across a period. An accreditation wants named procedures in a prescribed form.
| Obligation | Who decides | What it typically wants |
| A law | Nobody, until there is a question | The history of a particular record or decision, retrievable long afterwards |
| An attestation | An auditor you engage | Evidence that controls operated throughout a period, not on one day |
| An accreditation | A standards body, often on site | Named procedures and records in a prescribed form |
Only one of the three comes looking for you. The other two begin with your decision, so you set the timetable.
Where does a system fit in all of this?
Underneath all three, in the same place: whether the evidence exists before the question does. That argument is made at length elsewhere rather than repeated here. Our piece on built-in compliance covers why controls belong in the system rather than in a department that inspects afterwards, and audit readiness covers why needing a week to prepare is the symptom rather than the problem. Audit trails as an operational requirement makes the case for keeping the record at all.
Only one thing is worth adding. Because the three want different evidence, the useful question to ask of any system is not whether it is compliant, but what it keeps, for how long, and who can retrieve it. Our guide to user permissions covers the last of those, and sign-in records covers what the account records about arrivals.
Where should you start with compliance obligations?
By naming which of the three you are facing, in writing, before anybody chooses software.
It takes an afternoon, and it changes every question after it. Facing a law means knowing what your system could show about one record in four years. An attestation means controls that demonstrably operated all year. Accreditation means procedures matching somebody else’s standard. Buying for one while facing another is where the expensive surprises come from. To work out which you are facing, talk to an expert.
