// ArticleData.jsx — Verigo Global: full article content for all 8 resource articles
// Exposes window.ARTICLES_FULL

const ARTICLES_FULL = [
  {
    id: 'a1',
    cat: 'Strategy',
    title: 'SOC 2 vs ISO 27001: Which Certification Should You Pursue First?',
    date: 'June 12, 2026',
    read: '8 min',
    standard: 'soc2',
    relatedToolkit: 'soc2',
    relatedStandard: 'soc2',
    excerpt: 'Both are widely recognized, but they answer different questions for different buyers.',
    keyTakeaways: [
      'SOC 2 is an attestation that answers "are your controls operating?" — ISO 27001 is a certification that asks "is your management system working?"',
      'If your buyers are US-based SaaS procurement teams, start with SOC 2. If you sell into government or international enterprise, ISO 27001 opens more doors.',
      'The two frameworks share significant underlying controls — pursuing both is not double the work.',
    ],
    sections: [
      {
        heading: 'Two different questions',
        body: 'SOC 2 and ISO 27001 are both widely recognized marks of security maturity — but they are answering different questions for different audiences. SOC 2 is an AICPA attestation examination. A licensed CPA firm tests whether your controls were designed well (Type I) or operated effectively over a period of time (Type II) against the Trust Services Criteria. The deliverable is an independent auditor\'s opinion, and it is designed to answer the question your customers\' vendor-risk teams are actually asking: "Can I trust this supplier with my data?"\n\nISO 27001 is an international management system standard. An accredited certification body audits whether your Information Security Management System — its policies, processes, risk treatment, and continual improvement — conforms to the ISO/IEC 27001:2022 standard. The deliverable is a certificate, valid for three years with annual surveillance audits. It is designed to demonstrate organizational commitment and systematic control of information security risk.',
      },
      {
        heading: 'Who asks for which',
        body: 'The practical way to decide is to read the signals in your contracts and your prospect list. US-based SaaS providers, IT service companies, and managed service providers are almost universally asked for a SOC 2 report by their enterprise customers. Vendor-risk questionnaires, procurement security reviews, and MSA addenda now routinely require a current SOC 2 Type II report — usually issued within the last 12 months.\n\nISO 27001, by contrast, is the standard most commonly required by government and public-sector contracts (especially in the UK, EU, and the Middle East), large enterprise procurement in international markets, and any buyer who wants to see that the whole organization — not just the systems in scope for a single report — is managing information security systematically. In India, ISO 27001 certification is also closely associated with IT and BPO compliance with CERT-In and customer contract requirements.',
      },
      {
        heading: 'The overlap is larger than you think',
        body: 'Both frameworks are built on similar underlying principles: define scope, assess risk, implement controls, monitor effectiveness, improve continuously. The SOC 2 Common Criteria (CC1–CC9) and ISO 27001\'s Annex A share a substantial number of controls — access control, change management, incident response, backup, logging, and vendor management appear in both. A well-built SOC 2 control environment will already address a significant portion of the ISO 27001 control set, and vice versa.\n\nThis is why cross-framework mapping is so valuable. Our practitioners build a single evidence library that satisfies both frameworks simultaneously, so the quarterly access review you run for SOC 2 is also the ISO 27001 user access review. The CMMC 2.0 access control practices you implement serve your SOC 2 CC6 criteria. You do not have to build two programs — you build one program that earns multiple certifications.',
      },
      {
        heading: 'Sequencing the decision',
        body: 'If your buyers are US enterprise or SaaS procurement, start with SOC 2 Type I to enter the market quickly, then move into a Type II observation window. Once your control environment is mature — typically 12–18 months in — you will have most of the ISO 27001 documentation and evidence already in place. An ISO 27001 project from a mature SOC 2 program typically takes 3–6 months, not 12–18.\n\nIf your buyers are primarily international or government, the calculation reverses: ISO 27001 first gives you the broadest international recognition, and adding SOC 2 later is a natural extension for US market entry. Whichever you pursue first, build it the Compliance by Design way — so the second certification is a mapping exercise, not a rebuild.',
      },
    ],
  },
  {
    id: 'a2',
    cat: 'CMMC 2.0',
    title: 'How to Scope a CUI Enclave — and Why It Changes Your Level 2 Cost',
    date: 'June 3, 2026',
    read: '6 min',
    standard: 'cmmc',
    relatedToolkit: 'cmmc',
    relatedStandard: 'cmmc',
    excerpt: 'The single highest-leverage decision in a CMMC 2.0 program is defining your CUI enclave.',
    keyTakeaways: [
      'The CUI enclave is the boundary inside which all 110 NIST SP 800-171 controls apply — everything outside it is out of scope.',
      'A well-defined enclave can reduce in-scope systems by 60–80%, proportionally cutting assessment cost and effort.',
      'The SSP (System Security Plan) must fully document the enclave and every control within it — this is the primary artefact the C3PAO will examine.',
    ],
    sections: [
      {
        heading: 'Why scope is the most important decision',
        body: 'Every organization pursuing CMMC 2.0 Level 2 must implement all 110 NIST SP 800-171 controls — but "all 110 controls" applies only to the systems, people, and processes that handle Controlled Unclassified Information (CUI). Everything outside that boundary is out of scope for the C3PAO assessment. Defining that boundary — the CUI enclave — is therefore the single highest-leverage decision in your CMMC program. A poorly scoped enclave that includes your entire enterprise network means your entire enterprise network must meet all 110 controls. A well-defined enclave that contains only the systems that actually touch CUI can reduce the scope by 60–80%.',
      },
      {
        heading: 'What a CUI enclave is',
        body: 'A CUI enclave is a defined, bounded environment that contains all the systems, components, and people that create, receive, process, store, or transmit CUI. The boundary is documented in your System Security Plan (SSP) and supported by network diagrams, data flow diagrams, and asset inventories. The enclave is separated from the rest of your environment by technical controls — network segmentation, access controls, and boundary protection mechanisms that prevent CUI from flowing outside the defined scope.\n\nIn practice, a CUI enclave might be a GovCloud tenant (e.g., Microsoft Azure Government or GCC High) where all DoD contract work lives, isolated from the commercial infrastructure used for other customers. It might be a separate network segment with dedicated endpoints, VPN-enforced access, and a separate identity provider. The architecture varies; what matters is that the boundary is documented, enforced, and auditable.',
      },
      {
        heading: 'How to define your boundary',
        body: 'Start by tracing CUI flows: where does CUI enter your environment (contracts, drawings, specifications from the prime or the government), how does it move through your systems, who accesses it, where is it stored, and how does it leave (deliverables, reports, data returns). Every system that appears in that flow is in scope. Every person who has access to those systems is in scope. Every vendor with access to those systems is a subservice organization that must be assessed under CC9.2.\n\nOnce you have mapped the flow, design the architecture to minimize the enclave. Can the CUI-handling work be moved to a dedicated GCC High or GovCloud tenant? Can the team that touches CUI be limited to a defined group using dedicated endpoints? The goal is not to avoid controls — it is to apply them where they are needed and only where they are needed.',
      },
      {
        heading: 'The SSP is the centrepiece',
        body: 'Everything about your CUI enclave — the boundary, the assets, the people, the connections to external systems, and the implementation status of all 110 practices — is documented in the System Security Plan. The SSP is the primary artefact a C3PAO examines during a Level 2 assessment. A complete, accurate, well-maintained SSP is not just a compliance requirement — it is the instrument that demonstrates you understand your environment. Any practice you cannot document in the SSP is a finding. Any control gap documented in the SSP but not tracked in a Plan of Action and Milestones (POA&M) with a remediation date is a deficiency. Build the SSP and POA&M first; everything else flows from them.',
      },
    ],
  },
  {
    id: 'a3',
    cat: 'SOC 2',
    title: 'The Evidence Engine: How to Make Your Type II Observation Window Routine',
    date: 'May 22, 2026',
    read: '7 min',
    standard: 'soc2',
    relatedToolkit: 'soc2',
    relatedStandard: 'soc2',
    excerpt: 'The observation window is not the problem. The scramble before it is.',
    keyTakeaways: [
      'A Type II observation window does not require you to do anything new — it requires you to prove that your controls operated as designed throughout the period.',
      'The evidence engine embeds evidence generation into operational workflows: the quarterly access review, the weekly vulnerability scan, the change ticket — all generate evidence automatically.',
      'Each annual renewal should be lighter than the last as your evidence routines mature.',
    ],
    sections: [
      {
        heading: 'Why the observation window feels harder than it should',
        body: 'A SOC 2 Type II examination covers a period — typically 3 to 12 months — during which a CPA firm samples evidence that your controls operated as designed. Most organizations treat this as a project: they build the controls, then scramble to produce evidence for the window. The evidence collection effort typically consumes 4–6 weeks of engineering and compliance time per examination cycle. By the time the report is issued, the team is exhausted — and the next window starts immediately.\n\nThe root cause is a design error: the controls are built, but the evidence production is not. The access review exists in policy but is conducted manually and inconsistently. The vulnerability scan runs but the results are not stored in a retrievable, auditable format. The change management process works but leaves no clean audit trail. The observation window does not ask you to do anything new — it asks you to prove that you did it. If the process does not generate evidence automatically, you will always scramble.',
      },
      {
        heading: 'The evidence engine concept',
        body: 'An evidence engine is a set of operational routines that generate auditor-acceptable evidence as a natural output of how the organization works — not as a separate compliance activity. Each control in scope for your SOC 2 examination has three components: the policy that defines it, the procedure that operationalizes it, and the evidence routine that records it. When all three are in place, the control produces evidence continuously.\n\nFor access control, the evidence routine is the access review log — a quarterly report from your IdP, reviewed and signed off by system owners, stored in your GRC tool or a designated evidence folder. For change management, it is the change ticket — every production change recorded in your ticket system with an approval, a test result, and a deployment confirmation. For vulnerability management, it is the scan report — a weekly or monthly output from your scanner, with a remediation log showing how each finding was resolved or risk-accepted.',
      },
      {
        heading: 'Embedding into operations',
        body: 'The critical design principle is that evidence generation must be the natural output of how work gets done — not an additional step. If your engineers open a change ticket because that is how deployments happen, the change ticket is the evidence. If your IT team runs a quarterly access review because that is how they manage access hygiene, the review log is the evidence. If your security team triages vulnerability scanner output as part of their weekly routine, the triage record is the evidence.\n\nThis is what we mean by Compliance by Design: the controls are not bolted on after the work — they are built into how the work is done. The evidence exists because the process produces it, not because someone assembled it for the auditor.',
      },
      {
        heading: 'Making renewal lighter every year',
        body: 'In the first year, building the evidence engine requires effort: designing the routines, training the owners, establishing the cadences, and populating the evidence library for the first time. By the second examination, the routines are established and the effort is a fraction of year one. By the third year, the examination is genuinely routine — a matter of packaging evidence that already exists and submitting it to the auditor.\n\nThe key metric is the evidence-request (PBC) response time. In year one, responding to an auditor evidence request might take days. In a mature program, the evidence is pre-organized and response takes hours. That compression in audit support time is the most visible sign that your evidence engine is working.',
      },
    ],
  },
  {
    id: 'a4',
    cat: 'HITRUST',
    title: 'HITRUST Made Legible: Understanding e1, i1, and r2 Without the Jargon',
    date: 'May 8, 2026',
    read: '5 min',
    standard: 'hitrust',
    relatedToolkit: 'hitrust',
    relatedStandard: 'hitrust',
    excerpt: 'HITRUST certifications come in three types with very different scope, cost, and assurance level.',
    keyTakeaways: [
      'e1 covers 44 requirements and is the fastest path to a HITRUST certificate — ideal for organizations new to the framework or responding to a customer demand quickly.',
      'i1 covers 182 requirements and is the most commonly accepted level by health-sector buyers — a meaningful signal of cybersecurity maturity.',
      'r2 is the highest-assurance option with a tailored, risk-based requirement set — typically 200–800 requirements — and is the standard expected for high-value healthcare contracts.',
    ],
    sections: [
      {
        heading: 'Why HITRUST has three assessment types',
        body: 'HITRUST designed its three assessment types to serve different organizational risk profiles and stakeholder expectations. Not every organization needs the same level of assurance, and the cost and effort required to achieve each type varies significantly. The result is a tiered system: e1 for foundational cybersecurity hygiene, i1 for implemented leading practices, and r2 for a fully tailored, risk-based validated assessment. All three result in a HITRUST certificate; the difference is what that certificate demonstrates and who accepts it.',
      },
      {
        heading: 'e1 — Essentials, 1-year validity',
        body: 'The e1 assessment covers 44 requirements focused on essential cybersecurity hygiene: endpoint protection, multi-factor authentication, patch management, access control, and incident response fundamentals. It is the fastest and least expensive of the three options, and it is valid for one year. The e1 is a self-assessment submitted through MyCSF without a requirement for an authorized External Assessor — though HITRUST validates the submission.\n\nWhen is e1 right? When a customer or partner is asking for "some level of HITRUST" and you need to respond quickly, or when you are a smaller organization starting your HITRUST journey before scaling to i1. It is not accepted in place of i1 or r2 by most mature health-sector enterprise buyers, but it is a valid starting point and a signal of commitment.',
      },
      {
        heading: 'i1 — Implemented, 1-year validity',
        body: 'The i1 assessment covers 182 requirements across all 14 HITRUST CSF control categories, focused on implemented leading security practices. Unlike r2, the i1 requirement set is fixed — every organization at this level is assessed against the same 182 requirements, which makes it straightforward to scope and budget. An authorized External Assessor validates the submission.\n\nThe i1 is the most commonly requested level in healthcare IT procurement. Most enterprise health systems, health plans, and government health agencies that require HITRUST will accept i1 as evidence of meaningful cybersecurity maturity. If you have one HITRUST assessment to budget for and your customers are asking for i1 or "HITRUST certified," this is your target.',
      },
      {
        heading: 'r2 — Risk-based, 2-year validity',
        body: 'The r2 is the highest-assurance HITRUST assessment. The requirement set is tailored to your organization based on a set of organizational, system, and regulatory factors — the number of employees, the geographic footprint, the regulatory environment, the type of data processed. A typical r2 requirement set ranges from 200 to 800+ requirements. The assessment is validated by an authorized External Assessor, and the certificate is valid for two years with a one-year interim review.\n\nThe r2 is expected for the largest, most sensitive healthcare contracts: major health system vendor agreements, federal health IT contracts, and partnerships where a business associate\'s breach would create significant regulatory and reputational exposure. It is the most credible signal in the healthcare compliance market. It is also the most significant investment — plan for 9–18 months of preparation for an organization that is not yet HITRUST-certified.',
      },
    ],
  },
  {
    id: 'a5',
    cat: 'ISO 27001',
    title: "Why ISO 27001:2022's Four-Theme Annex A Changes Your Implementation Approach",
    date: 'April 17, 2026',
    read: '6 min',
    standard: 'iso27001',
    relatedToolkit: 'iso27001',
    relatedStandard: 'iso27001',
    excerpt: "Moving from 114 controls across 14 domains to 93 controls across four themes changes more than the numbering.",
    keyTakeaways: [
      'ISO 27001:2022 restructured Annex A from 114 controls across 14 domains to 93 controls across four themes: Organizational, People, Physical, and Technological.',
      '11 new controls were added, including threat intelligence, ICT readiness for business continuity, and data leakage prevention.',
      'The SoA must be rebuilt against the new Annex A structure — and the 11 new controls must be assessed for applicability even if excluded.',
    ],
    sections: [
      {
        heading: 'What actually changed',
        body: 'The ISO/IEC 27001:2022 revision replaced the 2013 Annex A entirely. The old standard had 114 controls organized across 14 domains (A.5 through A.18). The new standard has 93 controls organized across four themes: Organizational (37 controls), People (8), Physical (14), and Technological (34). The restructuring consolidated 24 pairs of controls that were essentially duplicates and reorganized the remaining controls to better reflect modern operational realities — cloud services, threat intelligence, and supply chain security now have explicit controls where they were previously implicit or absent.\n\nFor organizations currently certified against the 2013 standard, the transition deadline was October 2025 — all certificates should now reference the 2022 edition. For organizations starting their journey, the 2022 standard is the only target.',
      },
      {
        heading: 'The 11 new controls',
        body: 'The most significant addition is a set of 11 controls that did not exist in the 2013 standard. These cover areas that have become operationally critical in the intervening decade: threat intelligence (A.5.7), ICT readiness for business continuity (A.5.30), data leakage prevention (A.8.12), data masking (A.8.11), web filtering (A.8.23), configuration management (A.8.9), monitoring activities (A.8.16), information security for cloud services (A.5.23), and physical security monitoring (A.7.4), among others.\n\nThese are not aspirational additions — they reflect practices that well-run ISMS programs were already implementing informally. The 2022 revision makes them explicit requirements that must be addressed in the Statement of Applicability and either implemented or excluded with a documented justification.',
      },
      {
        heading: 'What this means for the SoA',
        body: 'The Statement of Applicability (SoA) is the instrument that connects the risk treatment plan to the Annex A controls. For the 2022 standard, the SoA must reference all 93 controls and document each as applicable or not applicable, with a justification for any exclusion. If you are updating an existing ISMS from the 2013 standard, you cannot simply remap old controls to new ones — the SoA must be rebuilt from the new Annex A structure.\n\nFor each of the 11 new controls, you must assess applicability against your risk treatment results. If your risk assessment does not identify a risk that the control addresses, you may exclude it — but the exclusion must be documented and defensible. In practice, most organizations implementing the 2022 standard will find that the majority of the 11 new controls are applicable to at least some degree.',
      },
      {
        heading: 'Implementation priorities',
        body: 'Practitioners implementing the 2022 standard for the first time should prioritize the Organizational and Technological themes, which together contain 71 of the 93 controls and cover the broadest surface area of a modern ISMS. The Technological theme in particular includes controls that are most likely to require changes to existing systems and tooling: configuration management, data masking, web filtering, and the cloud services control.\n\nFor organizations transitioning from the 2013 standard, the highest-priority gap work is the 11 new controls — assess applicability, implement or document exclusion, and update the SoA. The existing control set will largely map across to the new structure; the new controls are where the transition work concentrates.',
      },
    ],
  },
  {
    id: 'a6',
    cat: 'Risk Management',
    title: 'Risk Treatment in Practice: Accept, Mitigate, Transfer, or Avoid — and How to Document Each',
    date: 'April 2, 2026',
    read: '5 min',
    standard: null,
    relatedToolkit: 'iso27001',
    relatedStandard: 'iso27001',
    excerpt: 'Every framework requires a risk treatment decision, but most documentation is vague.',
    keyTakeaways: [
      'A risk treatment decision is only defensible if it includes the risk identified, the treatment option selected, the rationale, the owner, and the residual risk accepted by management.',
      'Acceptance is not avoidance — it is a deliberate, documented decision to tolerate a risk within the organization\'s risk appetite.',
      'Transfer (typically via insurance or contractual terms) does not eliminate the risk — it shifts the financial consequence, not the likelihood or the operational impact.',
    ],
    sections: [
      {
        heading: 'Why treatment decisions fail audits',
        body: 'Risk treatment is one of the most audited elements of any compliance program, and one of the most commonly found deficient. The most frequent finding is not that the wrong treatment option was chosen — it is that the decision cannot be demonstrated. A risk register that lists "mitigate" next to a risk, with no documented rationale, no owner, no target date, and no evidence of management review, is not a risk treatment plan. It is a list of intentions. Auditors and assessors are looking for documented evidence that the organization identified a risk, evaluated its options, made a deliberate decision, and accepted the residual risk at an appropriate level of authority.',
      },
      {
        heading: 'Mitigate',
        body: 'Mitigation is the most common treatment option: you implement one or more controls to reduce the likelihood or impact of the risk to an acceptable level. A mitigate decision is documented with the risk identified (threat, vulnerability, asset, and impact), the controls selected to reduce it, the rationale for why those controls address the risk, the owner responsible for implementing them, the target implementation date, and the residual risk that remains after controls are in place. The residual risk must be explicitly accepted by an appropriate authority — typically a risk owner or the CISO — at or below the organization\'s stated risk appetite.',
      },
      {
        heading: 'Accept',
        body: 'Risk acceptance is a deliberate decision to tolerate a risk without further action, because the cost of control exceeds the expected impact, the likelihood is sufficiently low, or the risk falls within the organization\'s risk appetite. Acceptance is not inaction — it is a documented, reviewed, and approved decision. A risk acceptance record should include the risk description, the reason acceptance is appropriate, the quantification of the expected impact and likelihood, the authority who accepted the risk, and the review date on which the decision will be revisited. Many organizations fail audits not because they accepted a risk they should have mitigated, but because the acceptance was undocumented or was never reviewed after circumstances changed.',
      },
      {
        heading: 'Transfer and Avoid',
        body: 'Transfer — most commonly through cyber insurance or contractual indemnification — shifts the financial consequence of a risk to a third party. It does not reduce the likelihood of the event or the operational impact; it only changes who bears the cost. Transfer decisions must document what is being transferred, to whom, under what terms, and what residual risk remains (most insurance policies have exclusions and deductibles that leave meaningful exposure). Avoid means eliminating the activity that creates the risk — shutting down a vulnerable service, discontinuing a product line, exiting a geography. It is the most decisive treatment option and is appropriate when the risk cannot be reduced to an acceptable level by any other means. Both options are valid; both must be documented with the same rigour as mitigation and acceptance.',
      },
    ],
  },
  {
    id: 'a7',
    cat: 'NIST CSF',
    title: 'NIST CSF Tiers vs Profiles: A Practical Guide to Using Both Without Confusion',
    date: 'March 19, 2026',
    read: '7 min',
    standard: 'nist',
    relatedToolkit: 'nist',
    relatedStandard: 'nist',
    excerpt: 'Tiers describe how you manage cybersecurity. Profiles describe what you do.',
    keyTakeaways: [
      'Tiers (1–4) describe the sophistication of your cybersecurity risk management practices — they are a maturity assessment of how you govern and manage cybersecurity, not what you have implemented.',
      'A Profile is a curated selection of CSF outcomes tailored to your organization\'s mission, risk tolerance, and resources — a Current Profile describes today; a Target Profile describes where you want to be.',
      'The gap between Current and Target Profile is the implementation roadmap. Tiers help you contextualize how much effort closing that gap will require.',
    ],
    sections: [
      {
        heading: 'The confusion',
        body: 'The NIST CSF is built around two complementary but distinct instruments — Tiers and Profiles — and they are frequently conflated, ignored, or used interchangeably. The result is CSF programs that either treat the Tier as a score to achieve ("we need to be at Tier 3") without implementing the underlying outcomes, or use the Framework Core without ever defining a Profile and therefore never measuring progress. Both instruments serve a real purpose; using them together, as NIST intended, produces a significantly more useful program.',
      },
      {
        heading: 'What Tiers actually mean',
        body: 'The four Implementation Tiers — Partial (1), Risk Informed (2), Repeatable (3), and Adaptive (4) — describe how your organization manages cybersecurity risk in relation to its mission and risk environment. They are not a maturity scale for individual controls; they characterize the organizational context in which cybersecurity decisions are made. A Tier 1 organization has informal, reactive practices and no formal risk management integration. A Tier 3 organization has formally approved risk management practices that are consistently applied across the organization. A Tier 4 organization continuously adapts its cybersecurity practices based on real-time threat intelligence and lessons learned.\n\nNIST is explicit that higher Tiers are not always better — the appropriate Tier is determined by the organization\'s risk tolerance, resources, and the criticality of its operations. A small professional services firm may be entirely appropriate at Tier 2; a critical infrastructure operator almost certainly needs Tier 3 or 4.',
      },
      {
        heading: 'What Profiles are for',
        body: 'A CSF Profile is a prioritized selection of outcomes from the Framework Core — the subcategories across all six functions — that your organization has decided to implement based on its mission, legal and regulatory requirements, risk appetite, and available resources. A Current Profile describes the outcomes your organization is achieving today. A Target Profile describes the outcomes you want to achieve. The gap between the two is your implementation roadmap.\n\nProfiles are intentionally flexible: two organizations in the same sector may have very different Profiles because their risk environments, customer commitments, and regulatory obligations differ. NIST provides sector-specific Profile guidance (for critical infrastructure, financial services, healthcare, etc.) as a starting point, but every Profile should be tailored to the specific organization.',
      },
      {
        heading: 'Using both together',
        body: 'The most practical way to use Tiers and Profiles together is to use the Tier assessment to contextualize the gap. Once you have a Current Profile and a Target Profile, the Tier tells you something about how much organizational change will be required to close the gap — not just what controls to implement, but how the organization needs to operate. A gap in the Govern function outcomes, combined with a Tier 1 or 2 assessment, signals that the issue is not just tooling but governance structure, accountability, and risk management integration. Closing it will require changes to how cybersecurity decisions are made and documented, not just additional security controls.',
      },
    ],
  },
  {
    id: 'a8',
    cat: 'Cross-framework',
    title: 'Certify Once, Reuse Everywhere: A Guide to Multi-Framework Compliance Programs',
    date: 'March 5, 2026',
    read: '8 min',
    standard: null,
    relatedToolkit: null,
    relatedStandard: null,
    excerpt: 'ISO 27001, SOC 2, CMMC 2.0, and NIST 800-171 share significant underlying controls.',
    keyTakeaways: [
      'The overlap between ISO 27001 Annex A, the SOC 2 Common Criteria, NIST 800-171, and the NIST CSF is substantial — access control, incident response, and change management appear in all four.',
      'The most efficient sequencing is typically: SOC 2 Type I → ISO 27001 → CMMC 2.0, with shared evidence collected once and mapped to multiple frameworks.',
      'A cross-framework control matrix — mapping each implemented control to every framework it satisfies — is the instrument that makes multi-framework compliance sustainable.',
    ],
    sections: [
      {
        heading: 'The overlap is the opportunity',
        body: 'Organizations pursuing multiple compliance certifications often assume they must build separate programs — a SOC 2 program, an ISO 27001 ISMS, a CMMC compliance posture. In practice, the underlying control requirements across these frameworks overlap significantly. Access control, multi-factor authentication, incident response, change management, backup, vulnerability management, logging and monitoring, and vendor risk management appear in ISO 27001 Annex A, the SOC 2 Common Criteria (CC6, CC7, CC8, CC9), NIST SP 800-171 (AC, IR, CM, RA, SI domains), and the NIST CSF (PR, DE, RS, RC functions). When you implement MFA for SOC 2 CC6.1, you are also satisfying ISO 27001 A.8.5, NIST 800-171 3.5.3, and NIST CSF PR.AA-03. The implementation is the same; only the reference differs.',
      },
      {
        heading: 'The cross-framework control matrix',
        body: 'The instrument that makes multi-framework compliance tractable is the cross-framework control matrix: a master spreadsheet that lists every implemented control and maps it to every framework requirement it satisfies. Each row is a control (e.g., "Quarterly access review"). Each column is a framework requirement (e.g., SOC 2 CC6.3, ISO 27001 A.8.5, NIST 800-171 3.1.3). The cell contains the evidence location — where to find the access review log that demonstrates the control operated.\n\nWith this matrix, responding to an auditor evidence request becomes a lookup, not a project. You already know which controls satisfy which requirements, and you know exactly where the evidence lives. Multi-framework programs without this matrix typically spend 2–3x more time on evidence collection than programs that have built it deliberately.',
      },
      {
        heading: 'Sequencing for maximum reuse',
        body: 'The most efficient sequencing for US-based organizations depends on your buyer mix and timeline. If you face immediate commercial pressure for a security attestation, start with SOC 2 Type I — it is the fastest path to a credible report. The control environment you build for SOC 2 — particularly the Common Criteria CC1 through CC9 — maps closely to ISO 27001 Clauses 4–10 and Annex A. By the time your Type II observation window closes (9–15 months after starting), you will have most of the ISO 27001 documentation already in place. An ISO 27001 certification project from a mature SOC 2 program typically takes 3–6 months.\n\nFor defense contractors with a November 2026 CMMC Level 2 deadline, start immediately with the NIST 800-171 control set — it is the foundation of CMMC 2.0. Many NIST 800-171 controls overlap with both SOC 2 and ISO 27001, so a CMMC-first approach can accelerate both subsequent certifications.',
      },
      {
        heading: 'Sustaining a multi-framework program',
        body: 'The sustainability challenge in multi-framework programs is not implementation — it is maintenance. When a control changes (a new access review process, a new incident response tool), the change must be reflected in the evidence for every framework the control satisfies. This requires a control ownership model where each control has a named owner who is responsible for both the operational implementation and the evidence record, and who understands which frameworks the control touches.\n\nOrganizations that sustain multi-framework programs successfully treat compliance as an operational discipline, not a project. The control owners are accountable not just for running the control but for keeping the evidence library current. The compliance team\'s job is to maintain the cross-framework matrix, coordinate with auditors, and flag when control changes create gaps. That division of accountability — control owners own the evidence; compliance owns the framework mapping — is the structural design that makes continuous multi-framework compliance sustainable.',
      },
    ],
  },
];

window.ARTICLES_FULL = ARTICLES_FULL;
