Cross-framework

Three different assurance questions, one disciplined control operation. A guide to sequencing and reusing evidence responsibly.

Explore standards advisory

What does each framework actually assess?

ISO/IEC 27001 specifies requirements for an information security management system: how an organization governs and improves information security risk within a defined scope. SOC 2 is an independent CPA examination of controls relevant to a described service organization system and the applicable Trust Services Criteria. ISO/IEC 42001 specifies an AI management system for responsible development, provision, or use of AI.

The outputs are different. ISO/IEC 27001 and ISO/IEC 42001 may be independently certified against their requirements. SOC 2 produces an attestation report, not a certificate. None of those outputs automatically satisfies every customer contract, privacy law, or AI-specific legal duty.

Which controls and records can be shared?

Start with operating activities: risk assessment, access control, change management, supplier review, incident response, training, internal audit, and management review. A single owner and evidence source can support more than one framework where the control actually covers the relevant asset, activity, and period. For example, a cloud access review may support an ISMS and a SOC 2 system if both include the same production environment.

Build a control register with purpose, scope, owner, frequency, evidence source, exception route, and framework mappings. Add AI-specific risk and impact assessments, testing, human oversight, and monitoring where the AIMS requires them. Shared evidence should be a consequence of shared work, not an assumption made by a mapping spreadsheet.

Where must the differences stay visible?

Scope is the first difference. A company-wide ISMS may cover teams and systems outside the SOC 2 service; an AIMS may include internal AI use that neither security scope previously addressed. Assessment periods also differ. SOC 2 evidence must match the report’s examined period, while management systems need an ongoing review and improvement cycle.

Criteria are another difference. Strong identity and incident controls do not establish that an AI system’s impacts have been assessed or that its oversight is appropriate. Equally, an AI inventory is not a substitute for security control operation. Keep requirement-specific evidence and decision records instead of forcing every item into one generic checklist.

How should a team sequence the work?

Let the buyer request and risk profile set the order. For a SaaS service facing a customer SOC 2 request, define the service and begin control operation early. For a business seeking organization-wide information security discipline, establish the ISMS foundation. If AI products or material AI use are already in scope, start the AIMS inventory and governance design in parallel so those decisions are not deferred until after the security milestone.

Use one integrated calendar for control reviews, internal audits, reporting periods, and management decisions. Give each independent assessor the records relevant to its scope. The payoff is less duplicated work and a clearer account of what has actually been assessed.

Put it into practice

  • Write a one-sentence purpose and scope for each intended assessment.
  • Inventory live controls before mapping them to requirements.
  • Track assets, periods, and AI-specific decisions alongside shared evidence.
  • Sequence independent assessment around actual buyer demand and operating readiness.

Primary sources

Normstone resources are general information, not legal advice or an independent assessment.

All resources