ISO/IEC 27001:2022 cut its Annex A control list from 114 controls to 93, but that consolidation didn't reduce the engineering work — it just regrouped the same access-control, encryption, and logging requirements under four themes instead of fourteen clauses. PCI DSS v4.0, published by the PCI Security Standards Council in March 2022, retired v3.2.1 on 31 March 2024, and then flipped a second set of "future-dated" requirements — expanded multi-factor authentication and targeted risk analyses among them — from optional to mandatory on 31 March 2025. (The Council issued a limited clarifying revision, v4.0.1, in June 2024 — it fixed wording and added applicability notes but introduced no new requirements, so v4.0.1 is the version currently in force.) Meanwhile SOC 2 has no fixed control list at all: auditors test your systems against the AICPA's five Trust Services Criteria, and HIPAA's Security Rule (45 CFR Part 164, Subpart C) splits its requirements into Administrative, Physical, and Technical safeguards without specifying implementation details. Four frameworks, four different vocabularies, four different audit cycles — and engineering teams that end up building the same access-control policy, the same encryption-at-rest configuration, and the same audit-log retention job four separate times because nobody wrote down where the frameworks actually overlap. This piece maps the controls so you can build once and reuse across every audit.
What does SOC 2 actually require you to build?
SOC 2 isn't a checklist — it's an attestation that your controls exist and work, tested against the AICPA's Trust Services Criteria. Security (the "common criteria") is mandatory for every SOC 2 report; Availability, Processing Integrity, Confidentiality, and Privacy are optional add-ons you select based on what you're selling. A Type I report attests that controls were suitably designed at a single point in time; a Type II report — the one most enterprise customers actually demand in vendor questionnaires — attests that those controls operated effectively across an observation period, typically three to twelve months. Engineering-wise, that means an auditor won't just ask "do you have an access-review policy," they'll ask for evidence: quarterly access-review tickets, the diff showing an offboarded employee's SSO access was revoked within a defined SLA, and CI logs proving a code-review gate actually blocked a PR at some point in the window. Point-in-time screenshots don't satisfy Type II; continuous evidence does.
What changed in ISO/IEC 27001:2022 and why does the count matter?
The 2022 revision restructured Annex A from 114 controls under 14 clauses down to 93 controls under four themes: Organizational (37), People (8), Physical (14), and Technological (34), according to ISO's own published mapping and third-party control-mapping analyses from firms like HighTable and ISMS.online. The reduction came from merging overlapping controls, not from dropping requirements — for example, several separate 2013-edition clauses on cryptographic controls, secure development, and outsourced development consolidated into fewer, broader Technological-theme controls. For engineering teams, the practical shift is that the Technological theme (34 of 93 controls) is where SAST, dependency scanning, logging, and cryptographic key management now live side by side, so a single well-instrumented CI/CD pipeline with vulnerability scanning, secrets detection, and audit logging can satisfy a meaningful fraction of that theme in one pass, rather than being evaluated against scattered legacy clauses.
What does PCI DSS v4.0.1 change for engineering teams specifically?
PCI DSS v4.0's biggest engineering-relevant shift is the future-dated requirement set that became mandatory on 31 March 2025 — until that date, items like expanded multi-factor authentication for all access into the cardholder data environment (not just remote access) and mandatory targeted risk analyses for controls with flexible implementation timing were "best practice only." Per the PCI Security Standards Council's own v3.2.1 retirement notice, any organization still validating against v3.2.1 after 31 March 2024 was non-compliant outright, giving teams a hard cutover rather than a grace period. Engineering-wise, v4.0 also formalizes customized implementation — you can design a control that meets the stated security objective differently from the defined approach, but you must document a targeted risk analysis justifying it, which turns "we do it our way" from a verbal explanation into an audit artifact. For anyone storing, processing, or transmitting cardholder data, that means MFA enforcement and risk-analysis documentation are no longer optional line items.
What does HIPAA's Security Rule require that the others don't?
HIPAA's Security Rule is the only one of these four frameworks scoped specifically to electronic protected health information (ePHI), and it structures its requirements into three safeguard categories — Administrative, Physical, and Technical — under 45 CFR Part 164, Subpart C, applying to both covered entities and their business associates. Technical safeguards are the closest analog to what security engineers build elsewhere: access control (unique user identification, automatic logoff, encryption), audit controls (hardware, software, and procedural mechanisms that record activity in systems containing ePHI), integrity controls, and transmission security. Where HIPAA diverges from SOC 2 or ISO is its Business Associate Agreement (BAA) requirement — any third-party vendor or subprocessor that touches ePHI needs a signed BAA, which makes vendor risk management a contractual gate, not just a security-review checkbox, and means your SBOM and third-party inventory need to track not just software supply chain risk but which vendors are contractually bound to HIPAA-equivalent safeguards.
Which controls satisfy all four frameworks at once?
Access control with least privilege, encryption at rest and in transit, audit logging with defined retention, formal change management, vulnerability and patch management, incident response, and vendor/third-party risk management appear — under different names — in all four frameworks and account for the bulk of the control volume in each. Build role-based access control with quarterly access reviews once, and it satisfies SOC 2's logical access criteria, a chunk of ISO 27001's Organizational and Technological themes, PCI DSS's Requirement 7/8 family, and HIPAA's Technical Safeguards access-control provision simultaneously. The same is true of audit logging: a centralized log pipeline with a documented retention period and tamper-evidence satisfies SOC 2 monitoring criteria, ISO 27001's logging controls, PCI DSS's Requirement 10, and HIPAA's audit-controls requirement in one implementation. The engineering lesson is to design controls at the level of "what does a SOC 2 Type II auditor, an ISO lead auditor, a PCI QSA, and a HIPAA compliance officer all need to see evidence of" rather than building four parallel, framework-specific implementations.
How Safeguard helps
Mapping the same control to four frameworks by hand is exactly the kind of repetitive cross-referencing that doesn't scale past the first audit cycle. Safeguard scores 197 compliance frameworks — including SOC 2 Type II, ISO/IEC 27001, PCI DSS v4.0, and HIPAA/HITECH — with per-control drill-down, so a single access-control or encryption finding shows you which specific clauses across all four standards it satisfies or violates, instead of re-running the mapping exercise for every new auditor. On the evidence side, Safeguard's automated SBOM compliance verification checks NTIA minimum-elements coverage against EO 14028 requirements and produces a gap analysis with a compliance score — a concrete example of the kind of continuous, queryable evidence that Type II auditors and PCI QSAs expect in place of point-in-time screenshots. The goal is the same one this cheat sheet is built around: build the control once, and let the framework mapping — not another engineering sprint — handle the next audit.