ISO 27001 vs SOC 2: Do You Need One or Both?

ISO 27001 and SOC 2 both help customers gain confidence in how an organisation protects information, but they are not the same kind of assurance.

• ISO/IEC 27001 is an international standard for establishing, operating and continually improving an information security management system (ISMS). A conforming organisation can be certified by an accredited certification body.
• SOC 2 is an attestation report prepared by an independent CPA firm on controls at a service organisation against applicable AICPA Trust Services Criteria.

The best choice depends less on geography alone and more on what customers ask for, what services are in scope and what assurance outcome procurement teams will accept.

Quick comparison

Treat this as an orientation. Your certification body, CPA firm and legal advisers should confirm the exact requirements for your circumstances.

What ISO 27001 assesses

ISO 27001 asks the organisation to run a risk-based ISMS. That includes defining scope, understanding interested parties, assessing information-security risk, selecting treatments, setting objectives, assigning responsibilities, operating controls, measuring performance and improving the system.

The 2022 edition's Annex A contains 93 controls grouped into organisational, people, physical and technological themes. Annex A is not a checklist that every organisation implements identically. The organisation selects controls in response to risk and explains applicability in its Statement of Applicability.

A certificate has a defined scope. Buyers should read that scope rather than assuming every product, office and subsidiary is covered.

What SOC 2 assesses

SOC 2 focuses on controls relevant to the AICPA Trust Services Criteria:

• Security.
• Availability.
• Processing integrity.
• Confidentiality.
• Privacy.

Security is foundational; the other categories are included as applicable to the service and commitments being assessed.

A Type 1 report considers control design at a specified date. A Type 2 report additionally considers whether controls operated effectively over a defined review period. Read the system description, criteria, exceptions and auditor's opinion rather than treating “SOC 2” as a binary badge.

When ISO 27001 may be the better first step

ISO 27001 may be the stronger starting point when:

• Customers request an internationally recognised ISMS certificate.
• The organisation needs a management framework spanning more than one product.
• European, UK or global procurement teams commonly ask for certification.
• Leadership wants a risk programme that extends across people, suppliers, physical security and technology.
• A supply-chain requirement names ISO 27001 explicitly.

Certification still needs a carefully defined scope. A narrow certificate may not answer a customer's question about a service outside that boundary.

When SOC 2 may be the better first step

SOC 2 may be the stronger starting point when:

• US enterprise buyers request a current Type 2 report.
• The assurance question centres on a particular SaaS or managed service.
• Customers need detailed information about control operation and audit exceptions.
• Service commitments map naturally to the applicable Trust Services Criteria.
• The sales process already includes controlled distribution and review of SOC reports.

SOC 2 reports contain sensitive system and control detail. Plan who can receive them and how customer questions will be handled.

When both make sense

Some organisations need both because their customers accept different evidence. If that is the case, build a shared control and evidence model instead of running two disconnected compliance projects.

Examples of reusable foundations include:

• Asset inventory and ownership.
• Risk assessment and treatment.
• Identity lifecycle and privileged access reviews.
• Secure development and change management.
• Supplier due diligence.
• Vulnerability management and penetration testing.
• Logging, monitoring and incident response.
• Business continuity and recovery exercises.
• Security training.
• Internal review and corrective action.

The wording, scope and sampling will still differ. A mapping shows relationships; it does not make evidence automatically sufficient for both auditors.

Where penetration testing fits

Neither framework should be simplified to “run one pentest per year.” The appropriate testing programme follows risk, system commitments, selected controls, customer contracts and the auditor's evidence expectations.

A well-scoped penetration test can help demonstrate that the organisation evaluates relevant technical controls in practice. Depending on the service, that may include:

• Web application testing of authentication, authorisation and business logic.
• API testing of service boundaries and data access.
• Cloud testing of identity, configuration and privilege paths.
• Network testing of external and internal exposure.
• Mobile testing of client-side and backend security.

The report should clearly state scope, dates, methodology, limitations, findings and status. Retesting should preserve evidence of what changed rather than overwriting the original result.

Pentestly delivers AI-augmented penetration testing through an in-house team. AI testing agents help broaden exploration; human testers control authorised actions, reproduce suspected weaknesses, assess business impact and approve every finding. Clients can manage findings, remediation and retesting in the portal.

Build one evidence system

1. Define scope before selecting tools

Identify the entities, services, people, technology and locations included in each assurance boundary. Reconcile differences explicitly.

2. Create a control crosswalk

Map each requirement to the actual control, owner, system and evidence source. Avoid copying generic mappings without validating how your implementation works.

3. Set evidence frequencies

Different controls produce evidence continuously, monthly, quarterly, annually or on change. Assign collection and review dates that reflect how the control operates.

4. Record exceptions honestly

An exception is information to investigate, not something to hide. Establish root cause, impact, corrective action, owner and target date.

5. Keep technical assurance connected

Link penetration-test findings to owners and remediation records. Preserve retest results and make recurring root causes visible to the risk and control owners.

Common decision mistakes

• Pursuing the framework a competitor mentions without asking customers what they require.
• Assuming a certificate or report covers the whole organisation.
• Comparing audit fees without internal implementation and evidence effort.
• Treating automated compliance tooling as ownership of the controls.
• Claiming a pentest proves overall compliance.
• Running separate evidence programmes for every framework.
• Publishing absolute “compliant” claims that exceed the audit scope.

FAQs

What is the main difference between ISO 27001 and SOC 2?

ISO 27001 is an international standard used to certify an organisation's information security management system. SOC 2 is an attestation report on controls at a service organisation against applicable Trust Services Criteria. They differ in structure, audience and audit outcome.

Can an organisation use the same controls for ISO 27001 and SOC 2?

Many underlying controls and evidence sources can support both, but the frameworks are not interchangeable. Map requirements deliberately, account for differences in scope and audit criteria, and confirm the approach with qualified auditors.

Is penetration testing required for ISO 27001 or SOC 2?

Neither creates one universal penetration-testing schedule for every organisation. The appropriate testing depends on risk, selected controls, system commitments, auditor expectations and customer requirements. A pentest can provide evidence that relevant technical controls are being evaluated.

Is a SOC 2 report a certification?

No. SOC 2 is an attestation report, not an ISO-style certification. Use precise language in sales and security documentation.

If a customer deadline is driving your technical-assurance work, speak to Pentestly about a scope and reporting timeline that can support the wider evidence programme.