Secure Controls Framework: A Comprehensive Overview

31 January, 2026

Security programs rarely fail because teams do not care. They fail because the work gets fragmented. One audit asks for ISO style evidence, a customer wants SOC 2 answers, privacy introduces new obligations, and suddenly you are running three versions of the same control set.The Secure Controls Framework, SCF, is built to fix that. 

SCF gives you one unified baseline for cybersecurity and data privacy, plus the structure to assess maturity, manage evidence, and turn gaps into clear improvement work. In this guide, we break down how SCF is structured, what is included in the model, how maturity and assessment work, and how you can implement SCF in a repeatable way.

Key Takeaways

• SCF helps you define one unified set of cybersecurity and data privacy controls, then map that baseline to multiple obligations without rebuilding your program each time.
• SCF is structured around domains and principles, backed by a large control catalog, so you can communicate intent clearly and still assess controls at a detailed level.
• The C|P CMM maturity model shows what “good” looks like over time, so you can move beyond yes or no compliance and track progress consistently.
• SCF includes assessment content like evidence request artifacts and assessment objectives, which makes audits more repeatable and reduces last minute evidence scrambles.
• SAMMY can support SCF implementation by helping you score maturity, attach evidence, manage improvement plans, and report progress through dashboards and maturity reports.

What is the Secure Controls Framework?

The Secure Controls Framework, SCF, helps you build one unified set of cybersecurity and data privacy controls, then map that baseline to many laws, regulations, and standards.

SCF is useful when you have overlapping obligations. Without a unified baseline, teams often document the same practice multiple times in different formats for different audits. SCF reduces that duplication by standardizing your control language once, then reusing it across requirements.

In SCF, control is not only technical. It can also be a policy, standard, procedure, process, or technology that helps ensure objectives are met and undesired events are prevented, detected, and corrected.

SCF is structured around 33 domains, expressed as Cybersecurity and Data Protection by Design principles. The principles set direction. The control catalog turns those principles into implementable requirements.

SCF also expects tailoring. Not every control is applicable to every organization, and implementation should be aligned to your statutory, regulatory, and contractual obligations.

How is the Secure Controls Framework structured?

SCF is easiest to understand as three layers: principles, controls, and mappings. Each layer serves a different purpose, and together they make SCF usable for both implementation and compliance reporting.

1) Domains and principles

SCF is organized into 33 domains. Each domain is expressed as a Cybersecurity and Data Protection by Design principle.

Think of principles as the “why” and “what.” They help you explain direction to stakeholders. They also help you check coverage, because a mature program should not ignore whole domains such as incident response, third party management, or vulnerability management.

Principles are also a great communication tool. You can use them in board level updates, risk committees, or product planning conversations without drowning people in control language.

2) The control catalog

The control catalog is the practical layer. This catalog is very extensive with over 1400 controls. This is where the principles become specific, testable expectations.

A single control record typically includes:

• The domain it belongs to
• A control statement, written as a requirement
• Guidance that helps teams implement it in real life
• Applicability signals, so you can scope it correctly
• A way to express maturity expectations, so you can define what “good” looks like over time

The important part is that SCF treats controls broadly. Many controls are technical, but many are also about governance, documentation, training, and operational discipline. That design makes it realistic for audits and for running a program, because security outcomes depend on people and processes, not just tooling.

3) Mappings to other frameworks

Mappings are the translation layer. They let you take a single SCF control baseline and show how it aligns to external obligations, such as regulations, industry standards, and contractual requirements.

This matters because most organizations do not have just one compliance driver. Mappings help you answer questions like:

• Which SCF controls support our SOC 2 commitments
• Which controls matter for our privacy obligations
• Where do we have gaps for a specific customer questionnaire

A key point here is that mappings are only valuable if your underlying baseline is coherent. If your controls are inconsistent, your mapping output will be inconsistent too. SCF’s structure is meant to prevent that by standardizing the control language first, then layering mappings on top.

How to use this structure in practice

Start with the domains and principles to communicate scope and intent. Then select and tailor the controls that apply to your organization. Finally, use mappings to report coverage against specific obligations, instead of rebuilding your program for each new framework.

What is included in the Secure Controls Framework?

Beyond the domains, controls, and mappings, SCF includes the operational content you need to run and assess a program in a repeatable way.

Maturity criteria (C|P CMM)

SCF includes maturity criteria for each control using levels from L0 through L5. This lets you move past simple yes or no compliance and define what “good” looks like as your program matures.

Evidence Request List (ERL)

SCF provides an Evidence Request List, ERL, which standardizes the types of artifacts assessors typically request and maps them back to SCF controls. It helps you build an audit ready evidence pack and reduces ad hoc evidence collection.

Assessment Objectives

SCF includes detailed assessment objectives that describe consistent ways to evaluate whether controls are designed and operating effectively. This supports repeatable testing across teams, business units, and third parties.

Threat and risk catalogs

SCF includes a threat catalog and a risk catalog, designed to connect control gaps to real world exposure. The idea is that if a control is weak, you should be able to translate that into threats and explicit risks, then prioritize action based on materiality.

Data Privacy Management Principles (DPMP)

SCF also includes Data Privacy Management Principles, DPMP. This adds a structured privacy management layer and mapping coverage for privacy frameworks and laws, which is useful if you need to operationalize privacy alongside security.

Why these extras matter

Most frameworks stop at “what controls should exist.” SCF also gives you content for maturity targets, evidence collection, control testing, and risk linkage. That combination is what makes it usable as a program backbone, not just a reference list.

How the Secure Controls Framework defines maturity: C|P CMM?

Most teams struggle with the same question: what does “done” look like for a control. A policy can exist, a tool can be deployed, and yet the control can still fail in practice. The SCF Capability Maturity Model for Cybersecurity and Data Privacy, C|P CMM, addresses this by defining maturity levels for each control, from not performed to continuously improving.

The maturity levels, in plain language

SCF uses six levels, L0 through L5:

• L0, Not performed: The control is missing.
• L1, Performed informally: The control happens sometimes, but it is inconsistent and depends on individuals.
• L2, Planned and tracked: The control is defined, evidence exists, and it is performed in a repeatable way.
• L3, Well defined: The control is standardized across the organization and embedded in normal operations.
• L4, Quantitatively controlled: The control is measured with meaningful metrics and managed based on data.
• L5, Continuously improving: The control is regularly improved, with feedback loops and predictive thinking.

A key concept is that maturity is nested. Each level builds on the one before it. You cannot realistically jump from informal activity to quantitative control without first making the control repeatable and then standardized.

A practical way to use it

For most organizations, a good starting target is L2 for the controls that are in scope. L2 is where controls become audit ready, because you can show defined expectations, execution, and evidence.

Over time, moving toward L3 is often where the real program payoff appears. L3 is about enterprise wide standardization. Instead of pockets of compliance, you get consistent practices across teams and business units. In that state, compliance becomes a byproduct of doing security and privacy work in a consistent way.

Keep it honest: maturity is not assurance

Higher maturity is generally a good sign, but it is not the same thing as security assurance. Maturity tells you how well a control is governed and managed. Assurance comes from how rigorously the control is tested and how confidently you can claim it works.

Example to pair with your screenshot: show one control’s maturity criteria, then explain that L2 evidence might include a documented standard, execution records, and a review cadence, while L3 evidence adds enterprise wide consistency, role based ownership, and integration into normal operating processes.

Assessment content in Secure Controls Framework: ERL and Assessment Objectives

A control framework is only as useful as your ability to verify it. That is where many programs break down. Teams adopt a control list, but assessment becomes inconsistent. Evidence requests change every time. Different auditors ask different questions. Internal reviews turn into opinion debates.

SCF addresses this by including assessment focused content that makes evaluation more repeatable.

Evidence Request List (ERL)

The Evidence Request List, ERL, is a curated list of the artifacts an assessor would typically request to validate controls. Importantly, these artifacts are mapped back to SCF controls.

This matters for three reasons.

First, it standardizes what “proof” looks like. Instead of inventing evidence requirements from scratch, you can align on a shared evidence baseline.

Second, it reduces audit scramble. When evidence expectations are predictable, teams can collect and maintain artifacts continuously, rather than reacting at the last minute.

Third, it scales. If you have multiple business units, systems, or third parties, a consistent evidence list makes assessments comparable across the organization.

Assessment Objectives

Assessment Objectives add another layer of consistency. They describe how to evaluate controls in a structured way. In practice, this means turning a control statement into repeatable testing steps.

A useful mental model is the classic three verbs: examine, interview, and test. Some controls can be validated through documentation alone. Others require interviews with control operators. Others require technical validation or sampling.

With assessment objectives, two different assessors can evaluate the same control and reach a similar conclusion, because they are following the same intent and evaluation guidance.

Why this content matters

ERL and Assessment Objectives shift assessments from “who is asking” to “what are we trying to prove.” That is what makes assessments more defensible. It also makes them easier to repeat.

If you plan to implement SCF, this assessment content is a major accelerator. It gives you a practical bridge between controls on paper and evidence in the real world.

Risk management in the Secure Controls Framework: control gaps to threats to risks

Many programs treat risk as a separate exercise. Controls live in one place, risk registers live somewhere else, and the link between them is mostly implied. SCF takes a different approach. The model is designed so that risks and threats map back to controls. That makes risk management more consistent, and it makes remediation easier to prioritize.

The core idea: risks and threats map back to controls

When a control is missing, weak, or inconsistent, you should be able to describe two things clearly.

First, which threats become more likely because the control is not doing its job. Second, which risks the business is now exposed to because those threats can materialize.

This is not just a reporting trick. It is what turns control assessments into business decisions. A gap is not a gap because an auditor said so, it is a gap because it increases exposure in a measurable way.

How to run a gap assessment with SCF catalogs

A practical SCF flow looks like this:

1. Assess the control, including current maturity.
2. Identify likely threats related to that control weakness using the threat catalog.
3. Translate the exposure into clear risk statements using the risk catalog.
4. Record the risk and decide on treatment.

This workflow prevents random risk questions that do not match your actual control framework. It also makes assessments repeatable, because you are always translating gaps using the same reference catalogs.

Risk treatment and risk acceptance authority

Once the risk is clear, there are four common treatment options:

• Reduce: improve controls to lower likelihood or impact
• Avoid: stop the activity that creates the risk
• Transfer: shift the risk through contracts or insurance
• Accept: formally accept the risk within defined limits

A key point is ownership. Security teams usually identify and report risks. However, business leadership should decide whether to accept them. Risk acceptance should also be limited to the right level of management. Low level managers should not be able to accept material risks on behalf of the organization.

Mini example: one gap, one threat, one risk, one decision

Imagine your organization has inconsistent patching for internet facing systems. The control exists, but it is informal and not tracked.

• Control gap: patching is not performed consistently or on schedule
• Threat: known vulnerabilities can be exploited because systems remain unpatched
• Risk: unauthorized access could lead to data exposure or service disruption
• Treatment decision: reduce risk by formalizing patch SLAs, tracking compliance, and escalating overdue patches, with clear ownership

This is the SCF advantage. Instead of stopping at “we failed a control,” you get a clear line from control maturity to threat exposure to business risk, and then to an explicit decision about what to do next.

How the Secure Controls Framework integrates privacy

SCF is designed to cover both cybersecurity and data privacy. It does this in two complementary ways.

First, privacy is present in the core structure. The domains and principles are framed as Cybersecurity and Data Protection by Design, so the model is not security only by default.

Second, SCF includes a dedicated privacy management layer called Data Privacy Management Principles, DPMP. DPMP helps you operationalize privacy work in a structured way, while still using SCF as the backbone.

DPMP, the privacy management layer

DPMP is a set of privacy management principles that is mapped to SCF. The practical outcome is that you can manage privacy expectations using the same control language you use for cybersecurity, instead of running two disconnected programs.

DPMP is also mapped to many privacy frameworks and privacy laws. This is useful if you operate across regions, or if you need to demonstrate alignment to multiple privacy sources without rebuilding your privacy program each time.

What DPMP covers

DPMP organizes privacy management into 11 domains:

• Privacy by Design
• Data Subject Participation
• Limited Collection and Use
• Transparency
• Data Lifecycle Management
• Data Subject Rights
• Security by Design
• Incident Response
• Risk Management
• Third Party Management
• Business Environment

These domains map well to how privacy is handled in real organizations. Some are clearly legal and governance focused, like transparency and rights. Others are operational, like lifecycle management, third party management, and incident response.

Why SCF plus DPMP matters

A common failure mode is treating privacy as paperwork. DPMP pushes privacy into operations. It gives you a way to connect privacy obligations to concrete practices, evidence, and assessments.

If you already run SCF for security, DPMP gives you a structured way to extend the same approach into privacy, with less duplication and more consistency.

Comparing SCF with other control frameworks: NIST 800-53, OWASP ASVS and CIS Critical Security Controls

SCF sits in a broader security and privacy ecosystem. Most organizations use more than one framework, because each one operates at a different layer. SCF is designed to be the unified control baseline across cybersecurity and privacy, with mappings and program artifacts that help you run, assess, and report on controls consistently. NIST SP 800-53 and the CIS Critical Security Controls provide enterprise focused safeguards, while OWASP ASVS defines application security requirements you can verify in software.

The table below compares these frameworks by purpose, structure, and scope, and shows how they complement each other.

SCF is most useful when you need one common control language across teams, audits, and obligations. NIST SP 800-53 is often the deepest enterprise catalog and can be a strong reference point for high assurance requirements, but it can be heavy to adopt without careful tailoring. CIS Controls provide a pragmatic, prioritized path to improve operational security. OWASP ASVS is different in kind, it focuses on verifiable application security requirements, making it ideal for product teams and AppSec validation.

In practice, a strong pattern is to use SCF as the overarching control baseline, then use CIS Controls to drive phased operational uplift, and use OWASP ASVS to define what “secure enough” means for application features and releases. This combination gives you organizational breadth, implementation clarity, and application level verification depth.

How to implement the Secure Controls Framework?

If you want to implement the Secure Controls Framework in a way that is structured, repeatable, and easy to report on, this walkthrough shows what that looks like in practice. In the video, we use SAMMY to run an SCF based assessment, score control implementation using a maturity model, and turn findings into a tracked improvement plan.

In this walkthrough you will see how to:

• Use SCF inside SAMMY.
• Score control implementation with maturity levels.
• Capture evidence using files, links, and remarks.
• Build improvement plans with owners and target dates.
• Monitor progress with dashboards and maturity reports.
• Set target postures and track maturity over time.

Frequently Asked Questions about the Secure Controls Framework

What is the Secure Controls Framework?

The Secure Controls Framework, SCF, is a unified set of cybersecurity and data privacy controls. It helps organizations define one control baseline and map it to multiple laws, regulations, and standards.

How many controls are in SCF?

SCF contains over 1,400 controls in the current model. The exact number can change between releases as the framework evolves.

What are the SCF domains?

SCF is organized into 33 domains. Each domain is expressed as a Cybersecurity and Data Protection by Design principle, which helps teams communicate scope and intent before getting into control detail.

Is SCF free to use?

SCF provides free content, including the core framework materials and resources published on its site. Some related services, training, or tooling may be offered separately by ecosystem providers.

What is the SCF maturity model?

SCF includes the C|P CMM maturity model, which defines maturity levels for each control from L0 to L5. This helps teams set clear expectations and track progress over time.

How does SCF compare to NIST 800-53, CIS Controls, and OWASP ASVS?

SCF is designed to be a unified baseline across security and privacy. NIST 800-53 is a deep enterprise control catalog, CIS Controls are a prioritized set of practical safeguards, and OWASP ASVS defines testable application security requirements. Many organizations use SCF as the backbone, then use CIS and ASVS to strengthen specific areas.

Is SCF a certification?

SCF is a framework. It can be used internally without any certification. Separate conformity assessment and certification programs exist, but they are not required to adopt the framework.

Conclusion

The Secure Controls Framework gives you a practical way to unify cybersecurity and privacy controls into one baseline you can explain, assess, and improve over time. Instead of managing overlapping requirements in parallel, you can tailor one control set, score maturity consistently, collect evidence in a repeatable way, and connect control gaps to clear risks and improvement priorities.

If you want to implement SCF with less manual effort, the walkthrough above shows how SAMMY supports SCF assessments, evidence management, improvement planning, and maturity reporting, so you can track progress with confidence and communicate outcomes clearly to stakeholders.

Official Resources

• Secure Controls Framework
• NIST 800-53
• CIS Critical Security Controls
• OWASP ASVS