Compliance Standards Demystified: Understanding SOC 2, ISO 27001, NIST

Intro: Security vs “Having a Cert”

Your enterprise sales prospect sends over a 30-page security questionnaire. Question 17 asks: “Do you have SOC 2 Type II?” You don’t. The deal stalls. This happens a few more times. Now you’re getting SOC 2.

That’s how most companies end up chasing compliance standards - not because they improve security, but because customers demand them. Sometimes it’s investors requiring it before Series B. Sometimes it’s insurance companies offering better rates. Sometimes it’s just checkbox compliance so procurement can check a box and move forward.

What these standards actually are: documented proof that you have security controls and you follow them consistently. That’s it. They don’t guarantee you’re secure. They guarantee you have processes and can prove it.

The difference between standards and regulations: regulations are law (GDPR, PSD2), Standards are voluntary frameworks that become requirements when customers or contracts demand them. Nobody goes to jail for lacking SOC 2. But you might lose the new customer deal, or not have access to a particular service provider which your product depends on.

Quick Mental Model: Same Ingredients, Different Recipes

Every compliance standard checks roughly the same things with different levels of detail and paperwork:

Access control: Who can access what, how do you grant/revoke access, is MFA enforced, are permissions reviewed regularly?

Change management: How do code changes reach production, who approves them, can you prove what changed and when?

Data protection: How is data encrypted (at rest, in transit), where are backups, how do you test recovery?

Monitoring and incident response: What gets logged, who reviews logs, what happens when something breaks or gets breached?

Vendor management: What third parties have access to data or systems, how do you vet them, what’s in the contracts?

Physical and environmental: Where are systems hosted, who has physical access, what about disaster recovery?

The maturity model progression:

1. Ad-hoc - “We do security stuff when we remember”
2. Documented - “We wrote down what we’re supposed to do”
3. Enforced - “We actually do what we wrote down”
4. Monitored - “We can prove we do it and catch when we don’t”

Most standards want you at level 3 minimum. SOC 2 Type II and ISO 27001 require level 4 (proof over time).

You don’t build the same controls three times - you build once and package the evidence differently for each framework. The actual controls required tend to be similar - only the paperwork and audit processes differ.

SOC 2: The US Enterprise Requirement

What It Is

SOC 2 is a report (not a certification) issued by CPAs (Certified Public Accountants) following standards from the AICPA (American Institute of CPAs). It evaluates your controls against Trust Service Criteria.

Type I vs Type II:

• Type I: Controls are designed properly (a point in time assessment)
• Type II: Controls operate effectively over time (minimum 3 months, usually 6-12 months)

Only Type II usually matters. Type I is “we plan to do security” and nobody cares. Type II is “we’ve been doing security for months and can prove it.”

The five Trust Service Criteria:

• Security: Mandatory, covers access control, encryption, monitoring, incident response
• Availability: Systems work when they should (uptime, DR, redundancy)
• Processing Integrity: Systems do what they’re supposed to (data accuracy, error handling)
• Confidentiality: Protecting confidential data beyond just security
• Privacy: Handling PII according to privacy policies

Security is the only mandatory criterion. The other four are optional add-ons you choose to include in your audit scope.

When You Need It

Enterprise sales requirements: Once you’re selling to mid-size or large companies, SOC 2 shows up in security questionnaires. Without it, deals take 6+ months of back-and-forth answering questions. With it, you attach the report and move on.

Security questionnaire fatigue: Answering the same 200 questions for every prospect gets old fast. SOC 2 report answers 80% of them.

Insurance and liability: Cyber insurance is cheaper with SOC 2. Some contracts require it for liability coverage.

You don’t need SOC 2 if you’re:

• Pre-product or early stage (build the controls, get audited later)
• Selling to SMBs who don’t ask for it
• Not handling sensitive customer data

What Auditors Actually Check

Control design: Is the control documented and logically sound? “We require code review before merging” is a control. “We hope people review code” is not.

Control effectiveness: Does the control actually operate? Auditors sample evidence. If your control says “code review required,” they’ll pull 25 random PRs and verify each has an approval.

Evidence: Everything needs proof. Policies, procedures, screenshots, logs, tickets, emails, meeting notes. If it’s not documented with a timestamp, it didn’t happen.

Policies and procedures you need:

• Access control policy (who gets access to what, how)
• Change management procedure (how code reaches production)
• Incident response plan (what happens when things break)
• Vendor management policy (how you vet third parties)
• Data classification and handling (what’s sensitive, how you protect it)
• Business continuity and disaster recovery plans
• Security awareness training materials

These don’t need to be fancy. A Google Doc with “this is how we do MFA” is fine if it’s accurate and you follow it.

What This Means for Engineering

Access control + SSO + MFA everywhere:

• SSO via Okta/Google/Azure AD for all systems
• MFA enforced, no exceptions
• Role-based access (not everyone is admin)
• Access reviews quarterly (verify people should still have access)
• Offboarding checklist (revoke all access when people leave)

Change management:

• All code changes via PRs
• Approval required before merge
• CI/CD logs showing what deployed when
• Ability to trace production change back to PR and approval

Asset inventory:

• List of all systems, services, and data stores
• Who owns each one
• Classification (production, staging, dev)
• Where they’re hosted

Centralized logging and alerting:

• Security-relevant events logged (authentication, authorization failures, config changes, data access)
• Logs retained for auditor-specified period (usually 1 year minimum)
• Monitoring for suspicious activity
• Incident response based on alerts

Vendor management:

• List of all third-party services with data or system access
• Security assessment for each (their SOC 2 report, security questionnaire, or contract terms)
• Data processing agreements where required

Evidence generation:

• Your systems should automatically generate evidence
• Git logs prove code review
• CI/CD logs prove deployments follow process
• Access logs prove MFA enforcement
• Ticket systems prove incident response

The goal: build systems where compliance evidence is a byproduct of normal operations, not extra work.

The Audit Process

Scoping (month 1-2): Define what’s in scope (usually production systems and data) and what’s out (marketing site, HR systems). Smaller scope = easier audit.

Readiness assessment (month 2-3): Internal review of controls and evidence. Find gaps before auditors do.

Audit period (month 3-6): Auditors request evidence, you provide it, they test controls. Expect weekly evidence requests.

Remediation (if needed): If controls fail testing, fix them and provide new evidence.

Report issuance (month 6-8): Auditor issues SOC 2 report. Valid for 12 months, then you re-audit.

Total timeline: 6-8 months from kickoff to report. Plan accordingly for sales cycles.

How Much It Actually Costs

Audit fees: $15K-50K depending on company size and scope. Small startups pay less, larger companies pay more.

Prep costs: Internal time (PM/engineering time to gather evidence and implement controls) or consultants ($20K-100K to help with readiness).

Tooling: GRC platforms like Vanta, Drata, Secureframe ($2K-5K/month) automate evidence collection.

Ongoing costs: Re-audit annually ($15K-30K), plus maintaining controls.

Budget $50K-150K first year all-in for a small company. Scales up with size.

ISO 27001: The International One

What It Is

ISO 27001 is an international standard for Information Security Management Systems (ISMS). Unlike SOC 2 (a report), ISO 27001 gives you a certificate issued by an accredited certification body.

It’s based on a risk management approach: identify risks, implement controls to mitigate them, document everything, and continuously improve.

When You Actually Need It

European enterprise customers: Many EU companies require ISO 27001, especially if they don’t recognize SOC 2.

Government contracts: Some governments require ISO 27001 for vendors.

Regulated industries: Financial services, healthcare in certain countries.

Global expansion: ISO 27001 is recognized internationally, SOC 2 is mainly US-focused.

If you’re primarily selling in the US, SOC 2 is usually enough. If you’re expanding to Europe or targeting international enterprises, add ISO 27001.

The ISMS and Why It’s Mostly Documentation

The ISMS is your documented security management system. It includes:

Scope: What’s covered (usually the whole company or specific products/services)

Risk assessment methodology: How you identify and evaluate security risks. Can be qualitative (“high/medium/low”) or quantitative (actual numbers). Most companies use qualitative because it’s easier.

Risk treatment plan: For each identified risk, what control you’re implementing or why you’re accepting the risk.

Statement of Applicability (SoA): Annex A of ISO 27001 lists 93 controls across 4 categories (organizational, people, physical, technological). You pick which controls apply to you and justify why you’re excluding others.

Policies and procedures: Similar to SOC 2 but more formal. Each control typically needs a policy.

Records: Evidence that you’re following the ISMS (meeting minutes, risk reviews, internal audits, management reviews).

The “mostly documentation” problem: ISO 27001 requires extensive paperwork. You need documented policies for everything, records of reviews, formal meetings. It’s heavier process-wise than SOC 2.

What This Means for Engineering

Config and infrastructure as code:

• Terraform/CloudFormation for infrastructure
• Ansible/Chef/Puppet for configuration
• Git history proving what’s deployed and when
• Ability to reproduce environments from code

Backup and DR documented and testable:

• Backup policies (frequency, retention, encryption)
• DR procedures (step-by-step recovery)
• Regular DR testing (quarterly or semi-annually)
• Documented RTO/RPO targets

Supplier management:

• Contracts with cloud providers, SaaS vendors
• Security assessment of each supplier
• Understanding where data is stored and processed

Secure SDLC artifacts:

• Code review process
• Static analysis (SAST) and dependency scanning
• Vulnerability management (how you patch)
• Security testing before releases

Risk assessment process:

• Regular risk reviews (at least annually)
• Documentation of identified risks and treatments
• Tracking risk changes over time

Asset inventory and classification:

• List of all information assets (databases, file stores, services)
• Classification (public, internal, confidential, restricted)
• Ownership and handling requirements

The Certification Process

Stage 1: Documentation review (1-2 days): Auditor reviews your ISMS documentation. Are policies written? Is SoA complete? Are processes documented?

Stage 2: Implementation audit (3-5 days on-site or remote): Auditor verifies controls are actually implemented. Interviews staff, reviews evidence, tests controls.

Certification decision: If you pass, you get certified. Certificate valid for 3 years.

Surveillance audits: Annually (between years 1-3), lighter audits to verify you’re maintaining the ISMS.

Recertification: Every 3 years, full re-audit (basically Stage 2 again).

Total timeline: 4-6 months from starting ISMS development to certification.

ISO 27001 vs SOC 2: Which First

Get SOC 2 first if:

• Primarily selling in US
• Customers asking for SOC 2 specifically
• Want faster time to certification (SOC 2 is lighter)

Get ISO 27001 first if:

• Primarily selling in EU/international markets
• Customers don’t know what SOC 2 is
• You already have mature processes and documentation

Get both (most common for scale-ups):

• Do SOC 2 first (6-8 months)
• Add ISO 27001 next (4-6 months, reusing SOC 2 evidence)
• Maintain both going forward

The overlap is significant. Access controls for SOC 2 map to ISO 27001 Annex A controls. Logging requirements are similar. You’re building the same controls, just documenting differently.

NIST Frameworks: The US Government-Flavored Options

What NIST Is

National Institute of Standards and Technology (NIST) is a US government agency that publishes cybersecurity frameworks and standards. Unlike SOC 2 or ISO 27001, there’s no NIST certification - you just “align with” or “implement” NIST frameworks.

NIST Cybersecurity Framework (CSF)

A voluntary framework organized into five functions:

• Identify: Understand your systems, assets, data, and risks
• Protect: Implement safeguards (access control, training, data security)
• Detect: Monitor for security events
• Respond: Have incident response plans
• Recover: Restore capabilities after incidents

Each function has categories and subcategories with specific outcomes. Example: Protect → Access Control → “Access to physical and logical assets is limited to authorized users, processes, and devices”

When companies reference NIST CSF:

• RFPs often ask “are you NIST CSF compliant?”
• It’s a maturity model - you map your controls to NIST and identify gaps
• No formal certification, just self-assessment or third-party validation

Using it as a maturity model: Rate each subcategory (Not Implemented, Partially Implemented, Implemented). Shows where you are and where you’re going.

NIST 800-53: Security Controls for Federal Systems

This is the detailed control catalog for US federal systems and contractors. Over 1,000 controls across 20 families (Access Control, Audit and Accountability, Configuration Management, etc.).

Control families: AC (Access Control), AU (Audit), CM (Configuration Management), IA (Identification and Authentication), IR (Incident Response), etc.

Baselines: Low, Moderate, High impact systems have different control requirements. Most systems need Moderate baseline (several hundred controls).

FedRAMP: Federal Risk and Authorization Management Program uses NIST 800-53. If you want to sell cloud services to US government, you need FedRAMP authorization. This is a massive undertaking - 12-24 months, $250K-1M+ in costs, extensive documentation and testing. Don’t pursue unless you have confirmed government deals.

NIST 800-171: Protecting CUI

Controlled Unclassified Information (CUI) is sensitive government information that’s not classified (things like procurement data, law enforcement info, health records).

If you’re a defense contractor handling CUI, you need NIST 800-171 compliance. It has 110 security requirements across 14 families.

DFARS clause: Defense contractors must implement NIST 800-171 and attest compliance. Penalties for false attestation include loss of contracts and potential criminal liability.

CMMC: Cybersecurity Maturity Model Certification is replacing self-attestation with third-party assessment for defense contractors. Coming in phases starting 2024-2025.

What This Means for Engineering

Endpoint and identity hardening:

• MFA on all accounts
• Device compliance (encrypted disks, up-to-date patches, EDR installed)
• Conditional access policies (block access from non-compliant devices)

Network segmentation and zero trust:

• Assume breach - don’t trust internal network
• Microsegmentation between services
• Application-level authentication and authorization
• Zero trust network access (ZTNA) instead of VPN

Vulnerability management with remediation windows:

• Continuous scanning for vulnerabilities
• Critical vulnerabilities patched within 15 days (NIST 800-171 requirement)
• High vulnerabilities within 30 days
• Tracking and reporting on patch status

Incident response runbooks tied to logs:

• Playbooks for common incident types
• Automated correlation of logs to detect incidents
• SIEM (Security Information and Event Management) for centralized analysis
• Regular tabletop exercises testing incident response

Why NIST Is Different

NIST frameworks are guidance, not prescriptive requirements (except when contracts mandate them). You can’t “get certified” in NIST CSF like you can with ISO 27001.

NIST 800-53 and 800-171 are prescriptive when required by contract (government work), but for commercial companies, they’re optional frameworks.

Many companies map their controls to NIST to show comprehensive security program, even if not required.

How They Map to Each Other

The good news: these standards check the same controls with different terminology.

Common core controls:

Where they differ:

SOC 2 is lighter and narrative. You write custom descriptions of controls. Flexibility to tailor to your business.

ISO 27001 is formal and structured. Specific Annex A controls to address. More documentation burden.

NIST is exhaustive and detailed. Hundreds or thousands of control requirements. Much more granular.

Using a control matrix: Build a spreadsheet mapping your implemented controls to all frameworks. When auditors ask for evidence, you provide the same evidence for multiple frameworks.

Example: Your MFA implementation satisfies SOC 2 CC6.1, ISO 27001 A.9.4.2, and NIST CSF PR.AC-7. One control, three checkboxes.

GRC tools (Governance, Risk, Compliance platforms like Vanta, Drata, Secureframe) automate this mapping. They collect evidence once and map it to all frameworks.

The practical reality: get SOC 2 first because it’s what most US customers ask for. Map your SOC 2 controls to ISO 27001 and NIST. When you need ISO 27001 certification, you’ve already done 80% of the work.

Evidence: The Part Everyone Underestimates

Auditors don’t take your word for anything. Every control needs evidence proving it operates.

What counts as evidence:

Git logs and PR approvals: Prove code review happened

• Pull request with approver name and timestamp
• Branch protection rules requiring approval
• Sample of 25+ PRs showing consistent approval

CI/CD run logs: Prove automated security checks

• SAST scan results in pipeline
• Dependency vulnerability scans
• Successful deployment logs with approver

Terraform plans and apply logs: Prove infrastructure changes are controlled

• Plan output showing proposed changes
• Apply logs showing who approved and executed
• Git history of Terraform code changes

Vault audit logs: Prove secrets access is monitored

• Who accessed which secrets when
• Failed access attempts logged
• Regular review of access logs

Access review spreadsheets: Prove periodic access reviews happen

• List of users with access to each system
• Review date and reviewer name
• Changes made based on review (access revoked, roles adjusted)

Incident response tickets: Prove incidents are handled per procedure

• Ticket showing incident detection, investigation, resolution
• Timeline matching incident response plan steps
• Post-incident review and lessons learned

Automating Evidence Collection

Manual evidence gathering is painful and error-prone. Automate it:

GRC platforms (Vanta, Drata, Secureframe):

• Connect to GitHub, AWS, Google Workspace, Jira, etc.
• Automatically collect evidence (screenshots, logs, API data)
• Track control compliance in real-time
• Alert when controls fail (MFA disabled, user without review)

Custom automation (if you’re not using GRC tools):

• Scripts that pull data from APIs (GitHub PR approvals, AWS CloudTrail logs)
• Store evidence in S3/GCS with timestamps
• Regular reports showing control compliance

The TicketOps trap: Creating Jira tickets the day before audit to show you “did the work” is obvious fraud. Auditors check timestamps. If all your quarterly access reviews happened the week before the audit, they’ll notice.

Build processes that generate evidence continuously, not when auditors ask.

Cloud Reality: AWS/GCP/Azure Shared Responsibility

Cloud providers have their own SOC 2 reports covering their infrastructure. Auditors accept these for the “physical and environmental” controls you can’t directly implement (data center security, power, cooling, physical access).

What auditors accept from cloud providers:

• Physical security of data centers
• Environmental controls (HVAC, power, fire suppression)
• Hardware disposal procedures
• Hypervisor and infrastructure security

What you still need to prove:

Network boundaries and segmentation:

• VPC configuration
• Security groups/firewall rules
• Network ACLs
• Subnets and routing tables

KMS key management:

• Customer-managed encryption keys
• Key rotation policies
• Who has access to keys
• Key usage logs

IAM policies and access controls:

• Principle of least privilege
• MFA enforcement
• Role-based access
• Regular access reviews

Backup configuration and testing:

• Automated snapshots/backups enabled
• Backup retention policies
• Cross-region replication
• Restoration testing records

Multi-tenant architectures and customer isolation:

• How you isolate customer data
• Tenant ID in all database queries
• Testing proving customers can’t access each other’s data
• Database or schema per tenant if needed

Infrastructure as code as evidence: Terraform/CloudFormation code showing your configuration is version controlled, reviewed, and reproducible. This is stronger evidence than screenshots of console settings.

What to Build Into the Platform

Don’t make developers think about compliance for every feature. Build it into the platform once:

Baseline scaffolding: SSO, RBAC, logging, secrets management, CI policies that apply to all services.

SSO integration: All internal and customer-facing applications use central identity provider (Okta, Google, Azure AD). Developers don’t implement auth, they integrate with SSO.

RBAC framework: Standard roles (read-only, developer, admin) with clear permissions. New services inherit RBAC patterns automatically.

Centralized logging: All services send logs to central system (Datadog, Splunk, ELK). Developers instrument code, logging infrastructure handles retention and search.

Secrets management: Services retrieve secrets from Vault/AWS Secrets Manager. No secrets in environment variables or config files.

CI policy enforcement: All repos have branch protection, required checks, deployment controls. Developers can’t bypass without approval.

Guardrails over guidelines: Don’t document “you should enable MFA” - enforce it at the organization level so it’s impossible not to.

Golden paths for new services: Service templates that include:

• Dockerfile with security best practices
• CI/CD pipeline with security scans
• Infrastructure-as-code with secure defaults
• RBAC integration
• Logging and monitoring configured

Developers use the template, they get compliance for free. They deviate from template, they need security review.

Making the secure path the easy path: If doing things securely is harder than doing them insecurely, compliance fails. Make secure defaults easier than insecure alternatives.

Common Pitfalls

“We’ll export logs later”: No you won’t. Build centralized logging from day one. Retrofitting logging into 50 microservices after they’re built is brutal.

Local admin accounts and shared credentials: Every service has its own admin/admin123 account that 10 people know. Auditors hate this. Use SSO with individual accounts and MFA.

Snowflake environments auditors can’t reproduce: Production is configured via ClickOps (clicking in console). Nobody knows what’s actually deployed or how to rebuild it. Use infrastructure as code so environments are reproducible.

Manual processes that can’t scale: “We manually review access every quarter” works for 10 people. At 100 people, it breaks. Automate what you can, especially access reviews and evidence collection.

Treating compliance as one-time project: You get SOC 2, celebrate, and stop maintaining controls. Next audit fails because you stopped doing quarterly access reviews six months ago. Compliance is ongoing, not a project with an end date.

Building controls that only work in production: Dev and staging environments have no access controls, logging, or monitoring. Then auditors ask “how do you prevent unauthorized access to staging data?” Build controls consistently across environments, adjusting for risk level.

Other Standards You’ll Hear About

HIPAA: Health Insurance Portability and Accountability Act. US regulation (not a standard) for protecting health information. If you handle Protected Health Information (PHI), you need HIPAA compliance. This is a separate beast - get specialized help if you’re in healthcare.

FedRAMP: Federal Risk and Authorization Management Program. Required for cloud services sold to US government. Massive undertaking - 12-24 months, $250K-$1M+, extensive documentation. Only pursue if you have confirmed government contracts worth the investment.

HITRUST: Healthcare-specific framework that combines HIPAA, ISO 27001, NIST, and other standards. Mostly used in healthcare. If you’re not in healthcare, you don’t need it.

CSA STAR: Cloud Security Alliance Security Trust Assurance and Risk program. Certification for cloud service providers. Rarely required unless you’re a cloud infrastructure provider.

When these actually matter:

• HIPAA: You’re building healthcare software
• FedRAMP: You’re selling to federal government
• HITRUST: Large healthcare enterprises require it
• CSA STAR: You’re competing with AWS/Azure/GCP