Compliance Requirements to Technical Controls: A Translation Table for SOC 2, NIST CSF, and ISO 27001
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Compliance frameworks are written for lawyers, not engineers. SOC 2 says you must have 'logical access controls.' NIST CSF says you must 'manage identities and credentials.' ISO 27001 says you must implement 'access control policy.' All three frameworks are describing the same technical control in three different languages, and none of them tells you what to actually build. This is the compliance translation problem. Security engineers know how to implement MFA, configure RBAC, enforce least privilege, and generate access logs. What they frequently lack is a reliable map from the auditor's abstract requirement to the technical implementation that satisfies it, and from that implementation to the evidence artifact the auditor will accept. This guide provides that map for 15 of the most commonly audited requirements across SOC 2, NIST CSF, and ISO 27001. It also documents the 43% evidence overlap between SOC 2 and ISO 27001 that most organizations treat as separate workstreams.
Why the Translation Problem Exists
Compliance frameworks are written to be technology-neutral. ISO 27001:2022 cannot specify that you must use a particular MFA provider because the standard needs to remain valid across organizations using different technology stacks, cloud providers, and time horizons. This technology neutrality is intentional and has real benefits. The same standard can apply to a hospital in Germany and a fintech in Singapore. The cost of that neutrality is abstraction. 'Appropriate technical and organizational measures' is a legally defensible phrase that means nothing to a security engineer sitting in front of a Terraform module. The gap between the abstract requirement and the specific control is where 65% of compliance failures originate. Organizations build real controls but cannot produce evidence that maps to the auditor's framework language. The control exists; the documentation connecting control to requirement does not.
SOC 2 Requirements: What They Mean Technically
SOC 2 Common Criteria are organized around the Trust Services Criteria. The three most frequently misunderstood requirements in security audits are CC6.1, CC6.2, and CC6.6.
CC6.1: Logical and Physical Access Controls
The abstract language asks for 'controls to restrict logical access to information assets.' The technical control that satisfies this is role-based access control with documented role definitions, enforced least-privilege provisioning, and access reviews conducted on a defined cadence (typically quarterly). The audit evidence an auditor will accept includes a screenshot of your IAM role matrix with assigned principals, a ticket or workflow record showing a recent access review was completed, and a sample access provisioning and de-provisioning record showing the approval chain.
CC6.2: Prior to Issuing Credentials
The abstract language requires that credentials be issued only after appropriate authentication. The technical control is an identity verification step in your user provisioning workflow, enforced via your IdP (Okta, Azure AD, Google Workspace). The audit evidence is a provisioning workflow diagram showing the verification step, plus a sample provisioning ticket showing the step was completed for a real user. Auditors will also accept a configuration screenshot of your IdP showing required verification fields.
CC6.6: Security Threats from Outside the System Boundaries
This criterion addresses external threats and is commonly interpreted as requiring perimeter controls. The actual technical scope includes firewall rules, intrusion detection, vulnerability scanning, and DDoS mitigation. Evidence auditors accept: a network diagram showing segmentation, a vulnerability scan report from the past 90 days showing remediation status, and firewall configuration exports showing only required inbound ports are open.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
NIST CSF 2.0 Requirements: The Technical Implementation
NIST CSF 2.0 is organized into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Protect function contains the identity and access requirements most frequently subject to audit. PR.AC-1 and PR.AC-4 are the highest-frequency requirements in SOC 2 crosswalk engagements.
PR.AC-1: Identities and Credentials Are Managed
The technical control is a centralized identity provider with enforced MFA, automated provisioning tied to HR system records, and a credential lifecycle policy covering password rotation, MFA enrollment, and de-provisioning on offboarding. Evidence: IdP configuration showing MFA enforcement policy, HR system integration diagram, and a de-provisioning record from within the past 30 days showing access was removed within your stated SLA.
PR.AC-4: Access Permissions and Authorizations Are Managed
This maps directly to least-privilege enforcement. The technical control is documented role definitions, a provisioning approval workflow, and periodic access certification. Evidence: role definition matrix exported from your IAM system, access certification campaign records (who reviewed, what was revoked), and a provisioning request showing the approval chain and role assigned.
DE.CM-1: The Network Is Monitored to Detect Potential Cybersecurity Events
The technical control is network detection capability with alerting. This is satisfied by NDR tooling (Darktrace, ExtraHop, Corelight), or by network flow logs ingested into a SIEM with detection rules applied. Evidence: SIEM dashboard screenshot showing network traffic ingestion, a sample alert from a detected anomaly, and documentation of the detection rules applied to network data.
ISO 27001:2022 Requirements: The Technical Mapping
ISO 27001:2022 reorganized the Annex A controls from 114 to 93, merging and updating several access control requirements. The most audited clauses in security assessments are A.5.15 (Access Control), A.5.16 (Identity Management), and A.8.2 (Privileged Access Rights).
A.5.15: Access Control
The control objective is that access to assets is authorized and restricted based on business and security requirements. The technical implementation is an access control policy document, an IAM configuration enforcing that policy, and documented business justification for elevated access. Evidence: the access control policy itself (must be dated and version-controlled), an IAM configuration screenshot, and a sample privileged access request showing business justification.
A.5.16: Identity Management
This requires a full identity lifecycle process. The technical implementation is a centralized directory, provisioning workflow tied to HR, and de-provisioning automation. Where SOC 2 CC6.2 focuses on credential issuance, A.5.16 covers the full lifecycle including modification and termination. Evidence: provisioning process diagram, HR integration configuration, and a terminated user record showing de-provisioning was completed on the same day as the HR action.
A.8.2: Privileged Access Rights
This specifically addresses privileged accounts: admin access, service accounts, and emergency access. The technical control is a privileged access management solution (CyberArk, BeyondTrust, HashiCorp Vault) or, at minimum, MFA enforcement on all privileged accounts, session recording, and a regular review of privileged account inventory. Evidence: privileged account inventory report, session recording configuration screenshot, and a quarterly review record showing privileged accounts were verified.
The 43% Evidence Overlap: Write Once, Satisfy Three
A-LIGN's 2025 Compliance Benchmark Report documented that 43% of evidence required for SOC 2 and ISO 27001 audits is identical or directly transferable. Organizations pursuing both certifications on separate timelines collect the same evidence twice, engage auditors twice, and run two parallel programs. Organizations that treat these as concurrent programs reduce audit prep time from 9-12 months to 4-5 months. The overlap is concentrated in access control evidence, incident response documentation, vendor management records, and change management logs. The following evidence artifacts satisfy requirements in all three frameworks (SOC 2, NIST CSF, and ISO 27001) simultaneously.
Access Review Records
A quarterly access certification record satisfies SOC 2 CC6.3, NIST CSF PR.AC-4, and ISO 27001 A.5.18 simultaneously. The record must show: the review date, the reviewer, the accounts reviewed, any accounts revoked, and the disposition of each account. One artifact; three framework requirements.
Vulnerability Management Reports
A scan report showing discovered vulnerabilities, CVSS scores, and remediation status satisfies SOC 2 CC7.1, NIST CSF ID.RA-1, and ISO 27001 A.8.8. The report must show the scan date, asset scope, findings, and remediation timeline. Quarterly scans with documented remediation SLAs satisfy all three.
Incident Response Records
A documented incident response procedure plus records of tabletop exercises or real incident closures satisfies SOC 2 CC7.3, NIST CSF RS.RP-1, and ISO 27001 A.5.26. The procedure must be version-controlled and reviewed annually; exercise records must show date, participants, scenario, and findings.
Change Management Logs
A change ticket log showing approval workflows for system changes satisfies SOC 2 CC8.1, NIST CSF PR.IP-3, and ISO 27001 A.8.32. The log must show the change requester, approver, approval date, and rollback plan. Ticketing system exports (Jira, ServiceNow) with these fields are accepted by auditors across all three frameworks.
Common Auditor Misconceptions About Controls
Auditors frequently use the word 'appropriate' to describe required controls. 'Appropriate encryption,' 'appropriate access controls,' 'appropriate monitoring.' This word does real legal work but communicates nothing to a security engineer. In practice, auditors have implicit baselines for what 'appropriate' means, and those baselines vary by auditor firm, industry vertical, and organization size.
What 'Appropriate Encryption' Actually Means
In SOC 2 and ISO 27001 audits, 'appropriate encryption' for data at rest means AES-256 at minimum. For data in transit, it means TLS 1.2 at minimum, with TLS 1.0 and 1.1 explicitly disabled. Using managed encryption services (AWS KMS, Azure Key Vault) satisfies the requirement if key management policies are documented. Auditors will ask for a configuration screenshot and a key rotation policy.
What 'Appropriate Logging' Actually Means
For most SOC 2 audits, 'appropriate logging' means: authentication events (success and failure), privileged actions, data access events for sensitive data, and system configuration changes. Logs must be retained for a minimum of 12 months and must be protected from modification. Auditors will ask for a log retention policy and a sample log showing the fields captured.
What 'Periodic Review' Actually Means
The word 'periodic' in compliance language is deliberately vague. In practice, auditors expect: access reviews quarterly, policy reviews annually, vendor risk assessments annually, and vulnerability scans at minimum quarterly. If your policy says 'periodic' without specifying frequency, auditors will ask what you define as periodic and then verify you met that definition.
What Certifications Mean and What They Do Not
A SOC 2 Type II report means an independent auditor reviewed your described controls and found evidence that those controls were operating effectively over the audit period, typically 6-12 months. It does not mean your environment is secure. It does not mean the controls cover your full attack surface. It does not mean the controls prevent breaches. What it does mean: your described controls existed, were documented, and produced evidence of operation. This distinction matters for security teams because certification can create false confidence internally. A passed SOC 2 audit frequently means the audit scope was well-managed, not that the security program is comprehensive. The most dangerous post-certification posture is treating the audit scope as the security scope.
The bottom line
Compliance and security are not the same discipline, but they share the most evidence when practitioners understand the technical requirements behind the abstract language. The 43% evidence overlap between SOC 2 and ISO 27001 is not an accident; both frameworks are trying to verify the same underlying security behaviors. Organizations that treat concurrent compliance as a documentation exercise rather than a controls exercise will continue spending 9-12 months per audit cycle. Organizations that map requirements to technical controls first, then generate evidence as a byproduct of operating those controls, reduce audit prep to the effort required to organize what already exists.
Frequently asked questions
What is the difference between SOC 2 Type I and Type II for technical controls?
SOC 2 Type I is a point-in-time assessment: an auditor reviews your controls as they exist on a single date and confirms they are suitably designed. SOC 2 Type II covers an audit period (typically 6-12 months) and requires evidence that controls operated continuously throughout that period. For technical controls, this means Type II requires operational evidence such as log exports, access review records, and change management tickets spanning the audit period, not just configuration screenshots taken before the audit.
Can the same technical control satisfy multiple compliance frameworks?
Yes. This is one of the most underutilized insights in compliance programs. A quarterly access certification process produces evidence that satisfies SOC 2 CC6.3, NIST CSF PR.AC-4, and ISO 27001 A.5.18 simultaneously. The key is documenting the control with enough specificity that the evidence artifact maps clearly to each framework's requirement language. GRC tools (Vanta, Drata, Tugboat Logic) automate this mapping and can reduce audit prep time by up to 75% according to A-LIGN's 2025 benchmark.
What evidence does an auditor actually look at for access controls?
For most SOC 2 and ISO 27001 access control requirements, auditors request three types of evidence: policy documentation (the written access control policy, dated and version-controlled), configuration screenshots (IAM settings showing enforcement of the policy), and operational records (access review records, provisioning tickets, de-provisioning records). Auditors will typically sample 25-40 individual access records during a Type II audit to verify the process is operating as described.
Why do 65% of compliance failures come from evidence gaps rather than control gaps?
Most mature security organizations have implemented real controls that would satisfy audit requirements. The failure point is documentation. Controls that operate without producing artifact evidence cannot be verified by an auditor. Examples include: access reviews conducted in spreadsheets that were overwritten, incident response exercises that were not documented, and configuration changes that bypassed the change management ticketing system. The control existed; the auditable evidence did not. Building controls to produce artifacts by default rather than requiring documentation as a separate step eliminates this failure mode.
How does NIST CSF 2.0 differ from CSF 1.1 for implementation purposes?
NIST CSF 2.0 added a sixth function, Govern, which addresses cybersecurity risk management strategy, roles and responsibilities, and policy. For implementation purposes, the most significant change is the addition of GV.OC (Organizational Context) and GV.RM (Risk Management Strategy) as formal subcategories. Organizations previously certified against CSF 1.1 will need to produce governance documentation (board-level risk appetite statements, documented CISO reporting lines, third-party risk management policies) that was not explicitly required in the prior version.
What is the fastest path to ISO 27001 certification if you already have SOC 2?
The fastest path leverages the 43% evidence overlap. Begin by mapping your existing SOC 2 evidence artifacts to ISO 27001 Annex A controls. For most organizations, access management, change management, incident response, and vulnerability management evidence transfers directly. The gap areas requiring net-new work are typically physical security controls (ISO 27001 A.7), supplier relationships (ISO 27001 A.5.19-5.22), and business continuity (ISO 27001 A.5.29-5.30). A-LIGN estimates that organizations with existing SOC 2 Type II reports can complete ISO 27001 certification in 4-5 months.
What does an auditor mean when they say a control is 'designed but not operating effectively'?
This is a SOC 2 finding category that specifically applies to Type II audits. It means: the control exists and is correctly designed, but the auditor found evidence during the audit period that the control did not operate as described. Common examples include: an access review policy stating reviews occur quarterly, but only one review was documented in a 12-month audit period; a vulnerability remediation SLA of 30 days for critical findings, but open critical findings older than 30 days present at the time of audit; or a change management policy requiring approval before deployment, but deployment records showing changes without tickets.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.