ISO 27001 and SOC 2 in 2026: One Control Program, Two Assurance Paths

Technology buyers increasingly ask the same supplier for an ISO/IEC 27001 certificate and a SOC 2 report. Treating those requests as two separate projects is expensive and usually produces two weak control libraries, two sets of screenshots, and conflicting ownership.

The better design is one security program with two assurance outputs.

ISO/IEC 27001:2022 specifies requirements for an information security management system (ISMS). SOC 2 is an independent CPA examination of controls relevant to the AICPA Trust Services Criteria. They differ in purpose, report form, audience, and audit method, but much of the operating evidence can be shared.

This guide is for a security, compliance, or operations lead deciding what to pursue, how to sequence it, and how to avoid rebuilding the same controls twice.

First choose the assurance outcome

Start with evidence, not fashion:

• Review the last 20 security questionnaires and contract redlines.
• Count how many opportunities explicitly require a certificate, a SOC 2 report, or either.
• Identify regulated customers and geographic markets.
• Confirm whether the requested scope covers the same product, legal entities, locations, cloud services, and supporting teams.

If customers accept either outcome, choose the one that removes the most sales friction. If both are commercially necessary, design a common scope first and stagger the assurance work.

What “93 controls” actually means

ISO/IEC 27001:2022 Annex A contains 93 reference controls grouped into four themes: organizational, people, physical, and technological. That does not mean every organization must implement all 93 in the same way.

The mandatory management-system process includes understanding context, setting scope, assessing and treating risk, defining objectives, operating controls, evaluating performance, conducting internal audit and management review, and correcting nonconformities. The organization then documents necessary controls and its rationale in a Statement of Applicability (SoA), including justified exclusions.

A spreadsheet that marks all 93 controls “implemented” without a traceable risk decision is therefore weaker than a smaller, well-supported control set.

For SOC 2, the security category's common criteria form the baseline. Availability, processing integrity, confidentiality, and privacy are added when relevant to the service commitments and system requirements. The system description and the organization's actual commitments matter; a generic control list is not enough.

Build one control-and-evidence model

Do not map standards to policy paragraphs alone. Map each obligation to an operating control and its evidence.

For every control, record:

1. the control objective and risk addressed;
2. the owner and backup owner;
3. the system population and scope;
4. the operating frequency;
5. the evidence source and retention period;
6. the exception and remediation workflow; and
7. the ISO and SOC criteria it supports.

This model prevents “evidence archaeology” at audit time. It also reveals controls that exist only on paper.

A practical 90-, 180-, and 365-day roadmap

Days 0–90: decide scope and make the system observable

• Define products, entities, locations, people, infrastructure, and data in scope.
• Document information flows and critical dependencies.
• Inventory contractual, legal, and customer requirements.
• Perform a risk assessment and approve a treatment plan.
• Build the SoA and a preliminary SOC 2 criteria map.
• Assign control owners and evidence frequencies.
• Fix high-impact basics: privileged access, offboarding, vulnerability handling, backups, logging, incident response, and supplier intake.

The deliverable is not “audit ready.” It is a governed backlog with clear ownership and reliable evidence sources.

Days 91–180: operate, sample, and correct

• Run recurring controls on schedule.
• Test evidence from complete populations, not hand-picked examples.
• Conduct security-awareness training and role-specific exercises.
• Test restore and incident procedures.
• Complete internal audit activities appropriate to the ISMS.
• Hold a management review with decisions and assigned actions.
• Close material gaps before starting a Type II review period.

A Type I report may be useful when a buyer needs a nearer-term design assessment, but it is not a substitute for sustained operation. If Type II is the commercial requirement, align its review period with the point at which controls are genuinely stable.

Days 181–365: complete assurance and sustain it

• Resolve readiness findings and confirm the final scope.
• Coordinate ISO certification stages and/or the SOC 2 examination.
• Track auditor requests through a controlled evidence workspace.
• Evaluate every exception for population impact rather than treating it as a one-off screenshot problem.
• Feed findings into corrective action, risk treatment, and management review.
• Establish a calendar for surveillance, the next SOC 2 period, policy review, supplier monitoring, and control changes.

Sequence both without running two programs

A common sequence is:

1. establish the ISMS and shared controls;
2. use readiness work to test evidence quality;
3. begin the SOC 2 Type II period once recurring controls are stable; and
4. schedule ISO certification when internal audit and management review are complete.

That is not a universal order. A customer deadline may justify a SOC 2 Type I first, while an international tender may make ISO certification the first milestone. The important choice is to keep the control owners, evidence populations, risk register, and corrective-action process common.

Budget by cost driver, not a headline price

Published “average certification cost” figures often hide the variables that matter. Build a budget from:

• number of products, entities, locations, and cloud environments in scope;
• workforce and control-owner count;
• maturity of access, change, incident, supplier, and resilience processes;
• number of SOC 2 categories selected;
• Type I versus Type II and the Type II review period;
• assessor effort, travel, penetration testing, and specialist work;
• remediation engineering and internal staff time; and
• ongoing surveillance, recurring examinations, and tooling.

For a smaller company, the most effective simplification is usually a narrow, defensible scope and fewer manual controls—not copied policies or an artificially short evidence period.

Automation: useful when it preserves context

Automation can collect cloud configuration, identity, ticketing, code, and device evidence. It cannot decide whether the scope is correct, whether an exception changes risk, whether a policy matches reality, or whether management accepted a residual risk knowingly.

Before buying a GRC platform, test whether it can:

• preserve evidence timestamps and source provenance;
• collect the complete population used for sampling;
• show control ownership and late operation;
• link exceptions to remediation and risk decisions;
• support a custom SoA and system description; and
• export evidence in a usable format.

Tool coverage percentages are not assurance conclusions.

Where AI Act and GDPR fit

ISO 27001 and SOC 2 can support cybersecurity, access, supplier, incident, and governance evidence used in GDPR and EU AI Act programs. They do not prove compliance with either law.

An AI system may still need classification, data-governance, transparency, human-oversight, technical-documentation, or fundamental-rights work that is outside the assurance scope. Personal-data processing still needs a lawful basis, transparency, rights handling, retention, security, and—where applicable—a data protection impact assessment.

Keep a legal-obligations register beside the assurance map so a customer-facing badge does not replace product-level compliance.

Audit-readiness checklist

• Scope matches customer claims, contracts, architecture, and the final assurance output.
• Risks trace to treatment decisions, controls, owners, and accepted residual risk.
• The SoA contains real inclusion and exclusion rationales.
• SOC 2 categories match service commitments and system requirements.
• Recurring controls have complete populations and consistent evidence.
• Exceptions have impact analysis, owners, due dates, and verified closure.
• Internal audit and management review produce decisions, not ceremonial minutes.
• Supplier, incident, continuity, access, and change processes have been exercised.
• Public claims accurately describe the certificate or report scope and period.

Frequently asked questions

Does a technology company need both ISO 27001 and SOC 2?

Not automatically. Choose the assurance format your customers, markets, and contracts require. A company selling globally may pursue both, but it should operate one risk-based control program and produce two assurance outputs rather than maintain two separate security systems.

Is SOC 2 a certification?

No. SOC 2 is an examination performed by an independent licensed CPA firm, resulting in a restricted-use attestation report. ISO/IEC 27001 certification is issued by an accredited certification body for an information security management system within a defined scope.

Does ISO 27001 require all 93 Annex A controls?

No. The organization assesses risk, determines necessary controls, compares them with Annex A, and documents inclusion or exclusion in its Statement of Applicability. The management-system clauses remain requirements; Annex A is a reference control set, not a universal 93-item checklist.

What is the difference between a SOC 2 Type I and Type II report?

Type I addresses whether controls were suitably designed as of a specified date. Type II also addresses operating effectiveness over a stated review period, so it requires sustained evidence rather than a point-in-time design review.

Can the same evidence support ISO 27001 and SOC 2?

Usually, yes. Access reviews, change records, incident exercises, risk decisions, supplier reviews, training records, backup tests, and governance minutes can support both when the scope, control owner, frequency, population, and retention rules are defined before evidence is collected.

Research and review note

This article was researched and reviewed on 7 October 2026 using the official ISO standard overview and AICPA SOC resources below. It distinguishes standard requirements, attestation concepts, and practical implementation guidance. Exact audit procedures, report distribution, certification decisions, and legal obligations depend on scope, contracts, the assessor, and applicable law.

Official sources

1. ISO — ISO/IEC 27001:2022 information security management systems
2. ISO — ISO/IEC 27000 family
3. AICPA & CIMA — System and Organization Controls suite of services
4. AICPA & CIMA — SOC 2 reporting guide