KeyvaciBlog · Compliance · 16 August 2026
ISO 27001 vs SOC 2:
what each demands of your credentials
Sooner or later an enterprise customer asks for one of them, and the fastest route to failing either is the same: shared passwords nobody can account for. Here is how the two standards actually differ, the credential controls each one checks, and the evidence an auditor will ask you to produce.
The two standards, without the mystique
ISO/IEC 27001 is an international standard for running an information security management system (ISMS). You define scope and risks, implement controls drawn from Annex A (93 controls in the 2022 revision), and an accredited body certifies you, with surveillance audits in between. It answers: does this organisation manage security systematically?
SOC 2 is an attestation, not a certification: a licensed CPA firm examines your controls against the AICPA Trust Services Criteria (Security always; Availability, Confidentiality, Processing Integrity, Privacy optionally) and writes a report. A Type I report says the controls were designed properly on a date; a Type II says they actually operated over a period, typically 3 to 12 months. It answers: can this vendor be trusted with customer data, with an auditor's evidence behind the answer?
| ISO 27001 | SOC 2 | |
|---|---|---|
| What it is | Certification of a management system | Auditor's attestation report on controls |
| Who asks for it | International and European enterprises, governments | North American enterprise buyers, SaaS procurement |
| Control set | Annex A, 93 controls (2022 revision) | Trust Services Criteria (CC-series plus optional categories) |
| Flexibility | Controls selected via risk assessment, exclusions justified | You define the controls; the auditor tests they operate |
| Output | Certificate, renewed on a 3-year cycle | Report (Type I or Type II), refreshed annually |
| Overlap | Substantial. Access control, credential lifecycle, logging, and cryptography sit at the heart of both | |
Similar frames exist elsewhere and rhyme with the same requirements: GDPR Article 32 ("appropriate technical measures", where encryption and access control are named explicitly), PCI DSS 4.0 (requirements 7 and 8: least privilege, 12-character minimums, MFA), HIPAA's access-control safeguards, and the UK's Cyber Essentials. Pass the credential discipline below and you are most of the way through the identity sections of all of them.
Where audits actually stall: shared credentials
Individual user accounts ride your identity provider and are easy to evidence. What stalls audits is the credential long tail that SSO cannot reach: the banking portal, the registrar, the shared admin login for the firewall, the API keys in scripts. Auditors under both standards ask the same four questions about exactly these:
- Inventory: what shared credentials exist, and who owns each one?
- Authorisation: who can access each, and does that match a documented need?
- Lifecycle: what happened when that person left in March? Show the record.
- Accountability: who actually used the shared account on this date? "It's shared" is a finding, not an answer.
A spreadsheet answers none of these; chat history answers them in the worst possible way. This is the gap a team credential vault exists to close, and it is why the fix is worth doing before the audit rather than for it: the same four questions are the ones a breach response asks under worse conditions.
The control map
| What the auditor checks | ISO 27001 Annex A | SOC 2 criteria | Evidence a vault produces |
|---|---|---|---|
| Access granted by role and need | A.5.15, A.5.18 | CC6.1, CC6.2 | Per-vault reader/writer/admin roles, listable per person in one query |
| Management of authentication information | A.5.17 | CC6.1 | Credentials stored encrypted with owners, strength gates, and age reminders instead of chat threads |
| Privileged access restricted and reviewed | A.8.2 | CC6.1, CC6.3 | Admin roles explicit per vault; access reviews read from the system, not from memory |
| Timely revocation on termination | A.5.18, A.6.5 | CC6.2, CC6.3 | Directory-linked sign-in dies with the account; vault revocation re-encrypts and is logged with a timestamp |
| Strong authentication | A.8.5 | CC6.1 | SSO with your IdP's MFA and Conditional Access; TOTP step-up before reveals |
| Event logging, protected from tampering | A.8.15 | CC7.2 | Append-only audit trail of opens, reveals, shares, and revocations that nobody, vendor included, can edit |
| Cryptography used appropriately | A.8.24 | C1.1 (Confidentiality) | Client-side XChaCha20-Poly1305 with Argon2id key derivation, documented publicly |
Control references are indicative, not a compliance opinion: your auditor and your scoping decide the final mapping. But every row above is a question we have seen an assessor ask in practice, and each becomes a five-minute answer when the evidence is a system of record instead of an interview.
Where Keyvaci fits, stated honestly
Keyvaci is the system of record for that shared-credential layer: vaults with enforced roles, sign-in through the directory you already audit, countersigned member keys, revocation that re-encrypts rather than hopes, and the append-only log that turns four auditor questions into four queries. The offboarding evidence that usually takes an afternoon of archaeology becomes a printout.
And our own side of the vendor-assessment table, stated plainly: Keyvaci is operated by XNOR Group Pte. Ltd., whose information security management system is certified to ISO/IEC 27001; the certificate and scope statement are available to your procurement team on request via the contact page. A SOC 2 report for the Keyvaci service itself is on the roadmap and not yet issued; we would rather say that than imply otherwise. Alongside the certificate, we offer something a badge cannot carry: a zero-knowledge architecture under which we cannot read what you store, published in enough detail for your security team to verify, plus a signed Data Processing Addendum. A vendor who can prove it holds only ciphertext is a vendor your auditors have very few questions for.
The practical sequence
- This week: move the shared-credential long tail into a vault with owners and roles; one afternoon for the top twenty.
- This month: wire sign-in to your directory so joiner-leaver evidence is automatic, and turn on MFA-before-reveal.
- At audit time: export the access lists and audit events for the sample the assessor picks, and spend the recovered days on the controls that actually need thought.
Make the credential section of your audit boring
14 days, every feature, no credit card. Sign in with company SSO or a plain email address.