Who’s Responsible? Everyone—and No One: Why Shared Responsibility Models Matter More Than Ever

In today's complex cybersecurity landscape, ambiguity in roles and responsibilities can lead to significant vulnerabilities. The concept of a Shared Responsibility Model (SRM) is pivotal in delineating clear boundaries between service providers and customers, ensuring that every aspect of security is accounted for.

This framework was a focal point in a recent presentation at the RSA Conference 2025, delivered jointly by Lawrence Cruciana, President of Corporate Information Technologies, and Matt Lee from Pax8, highlighting its critical role in modern cybersecurity strategies.

Understanding Shared Responsibility Models

A Shared Responsibility Model is a framework that defines the division of security responsibilities between service providers and their customers. While commonly associated with cloud services, SRMs are equally applicable to on-premises and hybrid environments. They ensure that both parties understand their roles in securing systems, data, and operations.

The Importance of Clarity

Without a well-defined SRM, organizations risk overlapping duties or, worse, leaving critical security tasks unaddressed. This lack of clarity can lead to incidents where each party assumes the other is responsible, resulting in delayed responses and increased damage.

CIS Controls v8.1

The Center for Internet Security (CIS) Controls v8.1 provides a comprehensive and actionable set of best practices for securing IT systems and sensitive data. These controls are designed to be accessible to organizations across a wide range of sizes, industries, and risk profiles.

The framework is divided into three Implementation Groups (IGs):

   Implementation Group 1 (IG1) is intended for small to mid-sized organizations with non-complex environments and minimal regulatory requirements. It defines essential cyber hygiene practices that serve as a foundational baseline.

   Implementation Group 2 (IG2) targets organizations with moderate complexity or oversight obligations, requiring more advanced security capabilities.

   Implementation Group 3 (IG3) is tailored for enterprises with sophisticated systems, sensitive data, or heightened exposure to advanced threats—such as those in defense, critical infrastructure, or heavily regulated sectors.

CIS Controls are organized around the guiding principle that “offense informs defense.” They are prioritized based on real-world data from incident responders, threat analysts, and red team operations to focus on the most effective and high-impact safeguards.

Each of the 18 CIS Controls is broken down into Safeguards (formerly known as sub-controls), which offer precise, implementation-ready actions. These Safeguards are mapped to the IGs, allowing organizations to scale their cybersecurity program based on resources, risk, and mission requirements.

This structured approach enables organizations to:

• Build risk-informed cybersecurity maturity.
• Strengthen operational resilience.
• Demonstrate compliance alignment with mandates such as CMMC 2.0, NIST 800-171, and industry-specific regulations.

By aligning shared responsibilities with CIS Controls, organizations can ensure that both internal teams and external partners uphold defensible, auditable, and proactive security measures.

Introducing the A.N.C.H.O.R. Framework

A – Agreed Metrics: Establish clear, measurable criteria for success and failure.

N – Named Scope: Define the exact systems, data, and processes covered.

C – Clear Responsibilities: Assign specific duties to each party, leaving no room for assumptions.

H – Handled Data: Identify data types involved and outline handling procedures.

O – Operational Specifics: Detail configurations, maintenance schedules, and other operational aspects.

R – Risks Identified: Recognize potential risks and determine how they are managed or transferred.

Applying ANCHOR to CIS Safeguards in Complex Ecosystems

The ANCHOR framework aligns naturally with specific CIS Controls v8.1 Safeguards, especially in regulated environments such as those guided by the Cybersecurity Maturity Model Certification (CMMC).

Here are examples of how ANCHOR elements connect with the safeguards of the CIS Controls in the context of an CMMC Organization Seeking Certification (OSC) working with an External Service Provider (ESP) or Cloud Service Provider (CSP):

• Agreed Metrics (A) → CIS Control 4.6, 4.7: Define log review frequency and response times between OSC and ESP to ensure thresholds for action are measurable and contractually enforceable.
• Named Scope (N) → CIS Control 2.1, 2.2: Maintain an up-to-date inventory of assets and software shared between OSC and CSP, with clear ownership noted in documentation.
• Clear Responsibilities (C) → CIS Control 17.3, 17.4: Establish documented roles for incident reporting, response, and coordination between the OSC and the ESP’s SOC.
• Handled Data (H) → CIS Control 3.3, 3.4: Ensure encryption responsibilities are defined at rest and in transit, with the CSP ensuring transport-layer security and the OSC managing application-layer protection.
• Operational Specifics (O) → CIS Control 5.2, 8.5: Require CSPs to configure automated access controls and specify audit log retention settings aligned with OSC compliance needs.
• Risks Identified (R) → CIS Control 18.1, 18.4: Conduct mutual risk assessments and define residual risk transference within shared responsibility matrices or customer responsibility documentation.

Prototypical Example 1 – OSC to ESP:

An OSC delegates patch management to an ESP. The SRM should reflect:

• A: ESP agrees to apply critical patches within 7 days.
• C: OSC retains responsibility for end-user workstations, while ESP covers infrastructure servers.
• O: Patch deployment and validation procedures are documented in operational runbooks shared between parties.

Prototypical Example 2 – OSC to CSP:

• H: CSP provides FedRAMP-equivalent encryption at rest; OSC manages file-level permissions.
• N: OSC clarifies that Exchange Online and SharePoint Online are in scope, while personal OneDrive is out of scope.
• R: CSP outlines shared risk for service outages, but OSC retains responsibility for data loss due to misconfiguration.
• N – Named Scope: Define the exact systems, data, and processes covered.
• C – Clear Responsibilities: Assign specific duties to each party, leaving no room for assumptions.
• H – Handled Data: Identify data types involved and outline handling procedures.
  • Operational Specifics: Detail configurations, maintenance schedules, and other operational aspects.
• R – Risks Identified: Recognize potential risks and determine how they are managed or transferred.

CorpInfoTech's Commitment to Cybersecurity Excellence

At Corporate Information Technologies (CorpInfoTech), we are proud to be a CIS-accredited organization, demonstrating our dedication to implementing and promoting these critical security controls. Our team applies CIS Controls at IG3 across a variety of customer environments, aligning with regulatory, operational, and contractual requirements to build resilient, secure, and auditable infrastructures.

To learn more about our services and approach, visit us at https://www.corp-infotech.com.

Conclusion

In an era where cyber threats are increasingly sophisticated, establishing a clear and effective Shared Responsibility Model is not just beneficial—it's essential. By utilizing frameworks like A.N.C.H.O.R. and aligning with CIS Controls v8.1 IG3, organizations can ensure that every aspect of their cybersecurity posture is addressed, responsibilities are clear, and risks are managed proactively.

For more information on how to implement these practices in your organization, visit Corporate Information Technologies at https://www.corp-infotech.com.