Introduction: The Secure Controls Framework (SCF)
The Secure Controls Framework (SCF) is a comprehensive, open-source catalogue of cybersecurity and data privacy controls maintained by the Secure Controls Framework Council. It was created to solve a persistent problem faced by every Chief Information Security Officer (CISO), compliance manager and auditor: the proliferation of overlapping laws, regulations and industry frameworks that each demand their own control language, evidence and reporting. Rather than forcing an organisation to maintain a separate control set for ISO/IEC 27001, NIST SP 800-53, the PCI DSS, the EU GDPR, India's DPDP Act, SOC 2 and dozens of others, the SCF provides a single 'metaframework' of controls that maps outward to more than 250 authoritative sources. Implement an SCF control once, and you can demonstrate coverage against every mapped requirement simultaneously.
This guide is written for two audiences at once. For the auditor or assessor, it enumerates the full structure of the SCF, the control domains, the maturity model used to grade capability, and the evidence typically expected during an assessment. For the implementer, CISO or GRC lead, it provides a phased implementation approach, roles and responsibilities, metrics and a readiness checklist. Throughout, the emphasis is on practical, auditor-grade specificity: what to verify, what evidence to collect, and how the SCF behaves differently from the prescriptive certification schemes most teams are accustomed to.
Copyright and licensing note
The Secure Controls Framework is published by the Secure Controls Framework Council, LLC under a Creative Commons Attribution-NoDerivatives (CC BY-ND) licence, which makes the catalogue free to use, including for commercial purposes, provided attribution is given and the content is not modified when redistributed. The related SCF Conformity Assessment Program (SCF CAP) and the Security & Privacy Capability Maturity Model (SP-CMM) documentation carry their own terms. This CyberSigma guide is an original work: it paraphrases and interprets the framework for educational purposes and does not reproduce the verbatim control text, mappings or copyrighted diagrams of the SCF. Organisations should always download the current authoritative spreadsheet from the official SCF source and honour the attribution requirement.
What is the SCF?
The SCF is best understood as a 'controls-as-a-service' reference library rather than a certifiable standard in the way ISO/IEC 27001 or the PCI DSS are certifiable. There is no accredited registrar that issues an 'SCF certificate'. Instead, organisations adopt the SCF as the internal control taxonomy against which they design, operate and assess their security and privacy programme, and then use the framework's extensive cross-mappings to prove conformity to whichever external obligations apply to them.
The framework is distinguished by several design principles. First, it treats cybersecurity and data privacy as a single, integrated discipline rather than two separate programmes, reflecting the reality that modern data protection laws impose security obligations and vice versa. Second, it is 'controls-centric': every requirement is expressed as an actionable control with a stable identifier, so that mappings remain durable even as source regulations evolve. Third, it is built around a defined maturity model, the Security & Privacy Capability Maturity Model (SP-CMM), allowing organisations to target and measure the capability level of each control rather than treating compliance as a binary pass or fail. Fourth, it deliberately incorporates the concept of 'reasonableness', drawing on legal doctrines such as the duty of care, so that control selection can be defended before regulators and courts.
- Open-source and free: the full control catalogue is distributed as a spreadsheet at no cost under CC BY-ND.
- Metaframework: over 250 mapped authoritative sources spanning laws, regulations, frameworks and contractual standards.
- Integrated: cybersecurity AND data privacy controls in one unified catalogue.
- Maturity-based: paired with the SP-CMM (levels 0 to 5) to express capability, not just presence.
- Risk- and threat-informed: paired with companion tools such as the SCF Risk Catalogue and Threat Catalogue.
- Defensible: aligned to the 'reasonable person' standard of due care and due diligence.
SCF versus certifiable standards
Do not describe the SCF as something an organisation 'gets certified against'. The SCF is the internal control fabric; certification (where required) still happens against the mapped external standard — for example, an ISO/IEC 27001 registrar audit or a PCI DSS QSA assessment — but the SCF ensures a single set of evidence supports all of them. The SCF Conformity Assessment Program (SCF CAP) is an emerging attestation scheme, but it is distinct from mandatory certification regimes.
Who must comply / scope of applicability
Because the SCF is voluntary and open-source, no law compels an organisation to 'comply with the SCF' per se. Applicability is therefore best framed as suitability: which organisations benefit from adopting the SCF as their control backbone, and which regulatory drivers push them towards it. The framework is deliberately industry-agnostic and scales from small enterprises to complex multinationals.
| Organisation profile | Why the SCF applies / typical driver |
|---|
| Multi-regulated enterprises | Firms subject to several overlapping regimes (e.g. GDPR + PCI DSS + SOC 2 + ISO 27001) use the SCF to avoid maintaining duplicate control sets. |
| Managed service and cloud providers | MSPs, MSSPs and SaaS vendors that must attest to many customer frameworks adopt the SCF to answer diverse due-diligence questionnaires from one control base. |
| Organisations pursuing multiple certifications | Teams targeting ISO 27001 and SOC 2 concurrently reduce effort by mapping once through the SCF. |
| Privacy-driven businesses | Entities under GDPR, CCPA/CPRA, India's DPDP Act 2023 or similar use the SCF's integrated privacy domains to unify security and data-protection controls. |
| US federal supply chain / contractors | Organisations aligning to NIST SP 800-53, SP 800-171 or CMMC use SCF mappings to trace controls to those catalogues. |
| Startups and scale-ups | Growing companies adopt the SCF early to build a scalable control taxonomy that will support future compliance needs. |
| Boards and legal counsel | Directors seeking a defensible 'reasonable security' posture value the SCF's alignment to duty-of-care principles. |
Scope of applicability within an adopting organisation is defined by the assets, systems, business processes, third parties and data flows that fall within the security and privacy programme boundary. As with any control framework, the first step is to draw and document that boundary before selecting controls.
Structure of the SCF
The SCF is organised hierarchically. At the top sit the control domains (commonly around 33 domains in recent releases), each identified by a short two-or-three letter code. Within each domain are individual controls, each carrying a stable identifier of the form DOMAIN-NN (for example, IAC-01). Every control has a control name, a control description (the objective and expected behaviour), a mapping to relevant authoritative sources, an associated SP-CMM maturity definition, and links to the SCF Risk and Threat catalogues. The following table lists the principal control domains and their focus. Domain codes and counts vary slightly by release, so always reconcile against the version you download.
| Domain code | Domain name | Focus |
|---|
| GOV | Cybersecurity & Data Privacy Governance | Programme governance, policies, standards, roles and steering. |
| AST | Asset Management | Inventory and control of hardware, software, data and services. |
| BCD | Business Continuity & Disaster Recovery | Resilience, backups, recovery objectives and continuity planning. |
| CAP | Capacity & Performance Planning | Resource planning to sustain availability and performance. |
| CHG | Change Management | Controlled change, approvals and configuration change records. |
| CLD | Cloud Security | Cloud service governance, shared responsibility and configuration. |
| CPL | Compliance | Statutory, regulatory and contractual obligation management. |
| MON | Continuous Monitoring | Logging, event monitoring, SIEM and situational awareness. |
| CFG | Configuration Management | Secure baselines, hardening and drift management. |
| CRY | Cryptographic Protections | Encryption, key management and cryptographic standards. |
| DCH | Data Classification & Handling | Data labelling, handling rules, retention and disposal. |
| EMB | Embedded Technology | IoT, OT, ICS and embedded/industrial device security. |
| END | Endpoint Security | Workstation, server and mobile endpoint protection. |
| HRS | Human Resources Security | Personnel screening, onboarding, offboarding and discipline. |
| IAC | Identity & Access Management | Authentication, authorisation, least privilege and account lifecycle. |
| IRO | Incident Response | Detection, response, containment, eradication and lessons learned. |
| IAO | Information Assurance | Assessment, authorisation and independent control validation. |
| MDM | Mobile Device Management | Mobile enrolment, policy enforcement and containerisation. |
| NET | Network Security | Segmentation, boundary protection and secure connectivity. |
| PES | Physical & Environmental Security | Facility access, environmental controls and secure areas. |
| PRI | Data Privacy | Privacy principles, data-subject rights and lawful processing. |
| PRM | Project & Resource Management | Security in project management and resource allocation. |
| RSK | Risk Management | Risk identification, assessment, treatment and acceptance. |
| SAT | Security Awareness & Training | Role-based awareness, training and phishing resilience. |
| SEA | Secure Engineering & Architecture | Security-by-design, defence-in-depth and secure architecture. |
| TDA | Technology Development & Acquisition | Secure SDLC, secure acquisition and supplier security. |
| TPM | Third-Party Management | Supplier due diligence, contracts and ongoing oversight. |
| THR | Threat Management | Threat intelligence, hunting and threat modelling. |
| VPM | Vulnerability & Patch Management | Vulnerability scanning, remediation SLAs and patching. |
| WEB | Web Security | Web application and web-facing service protections. |
| AIT | Artificial & Autonomous Technologies | Governance of AI/ML and autonomous systems (added in recent releases). |
| SES | Secure Engineering Standards | Standards for secure coding and system hardening (release-dependent). |
Master assessment checklist
This is the core section for auditors and implementers alike. For each SCF control domain below, an h3 heading introduces the domain and a table sets out representative controls, what an assessor should verify, and the typical evidence expected. The SCF contains over a thousand discrete controls in total; the tables here enumerate the principal control themes within every domain so that no control area is skipped. When performing an actual assessment, expand each theme to the specific DOMAIN-NN identifiers in the version you have adopted.
GOV — Cybersecurity & Data Privacy Governance
| What to verify | Typical evidence |
|---|
| A formal, board-approved security and privacy programme exists with defined scope and objectives | Programme charter, board minutes, approval records |
| Documented policies and standards are published, versioned and periodically reviewed | Policy library, version history, review dates, sign-off |
| Governance roles (CISO/DPO/steering committee) are assigned with authority and budget | Org chart, role descriptions, committee terms of reference |
| Controls are periodically reviewed for effectiveness and alignment to obligations | Governance review reports, action logs, KPIs |
AST — Asset Management
| What to verify | Typical evidence |
|---|
| A complete, current inventory of hardware, software, data and services is maintained | Asset register / CMDB export with owners and classifications |
| Assets have assigned owners and are tracked through their lifecycle | Ownership records, disposal/decommission logs |
| Unauthorised assets are detected and removed | Discovery scan output, rogue-device reports |
| Software is inventoried and only approved software is permitted | Software inventory, allow-list configuration |
BCD — Business Continuity & Disaster Recovery
| What to verify | Typical evidence |
|---|
| Business impact analysis defines RTO/RPO for critical services | BIA documents, RTO/RPO register |
| Backups are performed, protected and restoration is tested | Backup schedules, restore-test records, immutability config |
| Continuity and disaster-recovery plans exist and are exercised | BC/DR plans, exercise reports, after-action reviews |
| Alternate processing and communications arrangements are in place | Failover architecture, contracts for alternate sites |
CAP — Capacity & Performance Planning
| What to verify | Typical evidence |
|---|
| Capacity is forecast to meet current and future demand | Capacity plans, utilisation trend reports |
| Performance is monitored against defined thresholds | Monitoring dashboards, threshold-breach alerts |
| Scaling and resource provisioning follow a defined process | Autoscaling policies, provisioning records |
CHG — Change Management
| What to verify | Typical evidence |
|---|
| Changes follow a documented, approved change process | Change policy, CAB minutes, change tickets |
| Emergency changes are controlled and retrospectively reviewed | Emergency-change records and post-review notes |
| Changes are tested and have rollback plans | Test evidence, rollback procedures |
| Security review is part of significant changes | Security sign-off in change records |
CLD — Cloud Security
| What to verify | Typical evidence |
|---|
| Shared responsibility for each cloud service is documented and understood | Responsibility matrices per provider |
| Cloud configurations are hardened against secure baselines | CSPM reports, benchmark scan output |
| Cloud access, keys and secrets are governed | IAM policies, secrets-manager config, key rotation logs |
| Cloud logging and monitoring feed central visibility | Log-forwarding config, SIEM ingestion evidence |
CPL — Compliance
| What to verify | Typical evidence |
|---|
| Applicable statutory, regulatory and contractual obligations are catalogued | Compliance obligations register with owners |
| Controls are mapped to each obligation | Mapping matrix (SCF-to-source) |
| Compliance is monitored and non-conformities remediated | Compliance reports, corrective-action plans |
MON — Continuous Monitoring
| What to verify | Typical evidence |
|---|
| Security-relevant events are logged with sufficient detail and retention | Logging standard, retention config, sample logs |
| Logs are centrally aggregated and correlated | SIEM configuration, correlation rules |
| Alerts are triaged within defined timeframes | Alert queues, triage SLAs, ticket timestamps |
| Log integrity and access are protected | Immutable-log settings, access controls on log store |
CFG — Configuration Management
| What to verify | Typical evidence |
|---|
| Secure configuration baselines exist for each platform | Hardening standards, baseline documents |
| Systems are built from and measured against baselines | Provisioning templates, compliance-scan results |
| Configuration drift is detected and remediated | Drift reports, remediation tickets |
CRY — Cryptographic Protections
| What to verify | Typical evidence |
|---|
| Data is encrypted in transit and at rest per policy | Crypto standard, TLS/at-rest config evidence |
| Approved algorithms and key lengths are enforced | Cipher configuration, approved-algorithm list |
| Cryptographic keys are managed through their lifecycle | Key-management procedures, rotation and escrow records |
DCH — Data Classification & Handling
| What to verify | Typical evidence |
|---|
| A data classification scheme is defined and applied | Classification policy, labelled data samples |
| Handling, transmission and storage rules match classification | Handling matrix, DLP policies |
| Retention and secure disposal are enforced | Retention schedule, destruction certificates |
| Data loss prevention monitors sensitive data movement | DLP configuration and incident reports |
EMB — Embedded Technology (IoT/OT/ICS)
| What to verify | Typical evidence |
|---|
| Embedded, IoT and OT/ICS assets are inventoried and segmented | OT asset register, network segmentation diagrams |
| Firmware and embedded software are updated and controlled | Firmware update records, change logs |
| Physical and network access to embedded systems is restricted | Access control lists, OT DMZ configuration |
END — Endpoint Security
| What to verify | Typical evidence |
|---|
| Endpoints run approved protection (EDR/anti-malware) | EDR console coverage report |
| Endpoints are hardened and patched | Configuration-compliance and patch reports |
| Host firewalls and disk encryption are enforced | Policy screenshots, encryption status reports |
HRS — Human Resources Security
| What to verify | Typical evidence |
|---|
| Personnel are screened commensurate with role and risk | Background-check records |
| Onboarding and offboarding manage access and assets | Joiner/leaver checklists, access-revocation logs |
| Acceptable-use and confidentiality obligations are signed | Signed policies and NDAs |
| A sanctions/disciplinary process exists for violations | Disciplinary procedure records |
IAC — Identity & Access Management
| What to verify | Typical evidence |
|---|
| Identities are uniquely assigned and lifecycle-managed | Identity register, provisioning/deprovisioning logs |
| Strong authentication (MFA) is enforced for sensitive access | MFA policy and enforcement evidence |
| Least privilege and role-based access are applied | Role definitions, access-review records |
| Privileged access is controlled and monitored | PAM configuration, session logs, vaulting evidence |
| Periodic access recertification is performed | Recertification campaign results |
IRO — Incident Response
| What to verify | Typical evidence |
|---|
| An incident response plan defines roles, severities and workflows | IR plan, RACI, severity matrix |
| Incidents are detected, classified and contained in a timely manner | Incident tickets with timestamps and status |
| Regulatory and contractual breach-notification timelines are met | Notification records, timeline evidence |
| Post-incident reviews capture lessons learned | Post-incident review reports and action items |
IAO — Information Assurance
| What to verify | Typical evidence |
|---|
| Controls are independently assessed for effectiveness | Assessment reports, penetration-test results |
| Systems are formally authorised to operate where required | Authorisation letters / ATO records |
| Assessment findings are tracked to remediation | POA&M or remediation tracker |
MDM — Mobile Device Management
| What to verify | Typical evidence |
|---|
| Mobile devices accessing data are enrolled and managed | MDM enrolment reports |
| Policies enforce encryption, passcodes and remote wipe | MDM policy configuration |
| BYOD is containerised and segregated from corporate data | Containerisation configuration and BYOD policy |
NET — Network Security
| What to verify | Typical evidence |
|---|
| Network is segmented and boundary-protected | Network diagrams, firewall rule base |
| Ingress/egress traffic is controlled and inspected | Firewall/IPS configuration, rule reviews |
| Remote access is secured and monitored | VPN/ZTNA configuration and logs |
| Wireless networks are secured and separated | Wireless config, guest-network segregation |
PES — Physical & Environmental Security
| What to verify | Typical evidence |
|---|
| Physical access to facilities and data centres is controlled | Access logs, badge system reports |
| Secure areas protect critical systems | Zone plans, CCTV coverage evidence |
| Environmental controls protect against power/fire/climate risks | UPS, fire-suppression and HVAC records |
PRI — Data Privacy
| What to verify | Typical evidence |
|---|
| Lawful basis and purpose are documented for personal data processing | Records of processing activities (RoPA) |
| Data-subject rights are supported and fulfilled within deadlines | DSR request log with response times |
| Privacy notices and consent management are in place | Published notices, consent records |
| Privacy impact assessments are conducted for high-risk processing | DPIA records and outcomes |
| Cross-border transfers use lawful mechanisms | Transfer impact assessments, SCCs/adequacy records |
PRM — Project & Resource Management
| What to verify | Typical evidence |
|---|
| Security and privacy requirements are embedded in projects | Project security requirements, gate reviews |
| Resources and budget are allocated to security tasks | Resource plans, budget allocations |
RSK — Risk Management
| What to verify | Typical evidence |
|---|
| A documented risk-assessment methodology is applied | Risk methodology, risk register |
| Risks are assessed, treated and re-assessed periodically | Risk treatment plans, review dates |
| Risk acceptance is authorised at the appropriate level | Signed risk-acceptance records |
SAT — Security Awareness & Training
| What to verify | Typical evidence |
|---|
| All staff receive security and privacy awareness training | Training completion records |
| Role-based training targets high-risk roles | Role-specific curricula and completion data |
| Phishing simulations and awareness measures are run | Phishing campaign results and trends |
SEA — Secure Engineering & Architecture
| What to verify | Typical evidence |
|---|
| Security-by-design and defence-in-depth principles guide architecture | Architecture standards, design reviews |
| Reference architectures and threat models exist for key systems | Reference architecture docs, threat-model outputs |
TDA — Technology Development & Acquisition
| What to verify | Typical evidence |
|---|
| A secure SDLC governs in-house development | SDLC policy, security-testing gates |
| Code is scanned for vulnerabilities before release | SAST/DAST/SCA scan reports |
| Security requirements are embedded in acquisitions | Procurement security clauses, evaluation records |
TPM — Third-Party Management
| What to verify | Typical evidence |
|---|
| Third parties are risk-assessed before engagement | Vendor due-diligence and risk-tiering records |
| Contracts include security, privacy and breach-notification clauses | Executed contracts / DPAs |
| Ongoing supplier performance and risk are monitored | Supplier reviews, attestations (SOC 2, ISO), reassessments |
THR — Threat Management
| What to verify | Typical evidence |
|---|
| Threat intelligence is collected and actioned | Threat-intel feeds, briefing records |
| Threat modelling and hunting are performed | Threat-model documents, hunt reports |
VPM — Vulnerability & Patch Management
| What to verify | Typical evidence |
|---|
| Systems are regularly scanned for vulnerabilities | Scan schedules and reports |
| Remediation SLAs are defined by severity and met | SLA policy, remediation timelines, exception register |
| Patches are tested and deployed within timeframes | Patch reports, deployment records |
WEB — Web Security
| What to verify | Typical evidence |
|---|
| Web-facing applications are protected (WAF, secure headers) | WAF config, header scan results |
| Web applications are tested for common vulnerabilities | Application pen-test / OWASP test reports |
AIT — Artificial & Autonomous Technologies
| What to verify | Typical evidence |
|---|
| AI/ML and autonomous systems are inventoried and governed | AI system inventory, AI governance policy |
| AI risks (bias, safety, data provenance) are assessed | AI risk assessments, model documentation |
| Human oversight and accountability for AI decisions exist | Oversight procedures, decision-review records |
Scoping and materiality/tiering
Unlike a prescriptive standard where every control applies equally, the SCF expects organisations to scope and tier their control selection. Scoping determines which assets, processes and data are in-boundary; tiering determines how rigorously each control must be implemented. The SCF supports this through the concept of applicable controls driven by the organisation's obligations and risk appetite.
- Define the programme boundary: which entities, systems, data types, geographies and third parties are in scope.
- Identify all applicable authoritative sources (laws, regulations, contracts, frameworks) — these drive which SCF controls become mandatory.
- Tier controls by data sensitivity and system criticality — the higher the impact, the higher the target SP-CMM level.
- Apply materiality: focus assurance effort on controls protecting the most material risks and regulated data.
- Document scoping decisions and any exclusions with justification, so assessors can challenge them.
Reasonableness as a scoping test
The SCF explicitly aligns to a 'reasonable person' standard. When deciding how far to implement a control, ask what a reasonable, prudent organisation of similar size, sector and risk exposure would do. Documenting this reasoning is itself defensible evidence of due care.
Implementation approach
A structured, phased rollout keeps an SCF adoption manageable. The following phases move from mobilisation through to continuous improvement, with activities and deliverables for each.
Phase 1 — Mobilise and scope
- Activities: secure executive sponsorship; establish governance; define programme scope and boundary; identify applicable authoritative sources.
- Deliverables: programme charter, scope statement, obligations register, project plan.
Phase 2 — Select and map controls
- Activities: download the current SCF catalogue; filter to applicable controls via mappings; set target SP-CMM level per domain; map SCF controls to existing controls.
- Deliverables: tailored SCF control set, control-to-obligation mapping matrix, target-maturity baseline.
Phase 3 — Gap assessment
- Activities: assess current state against target SP-CMM levels; document gaps and root causes; risk-rank gaps.
- Deliverables: gap-analysis report, prioritised remediation backlog.
Phase 4 — Remediate and implement
- Activities: implement or uplift controls; write/update policies and standards; deploy tooling; train staff.
- Deliverables: implemented controls, updated policy library, evidence artefacts, training records.
Phase 5 — Validate and attest
- Activities: internal assessment against SP-CMM; independent review or SCF CAP-style attestation; map evidence to external certifications.
- Deliverables: assessment report, maturity scorecard, certification-readiness pack.
Phase 6 — Operate and improve
- Activities: continuous monitoring; periodic reassessment; update for new obligations and SCF releases; drive maturity upward.
- Deliverables: KPI dashboards, reassessment reports, improvement roadmap.
Maturity model (SP-CMM)
The SCF is paired with the Security & Privacy Capability Maturity Model (SP-CMM), a six-level scale used to express and target the capability of each control. Maturity is assessed per control (or per domain) and target levels are set according to risk and obligation. The table below summarises the levels.
| Level | Name | Characteristics |
|---|
| 0 | Not Performed | The control is absent; no evidence of the practice exists. |
| 1 | Performed Informally | Ad hoc and reactive; the control happens but is not documented or repeatable. |
| 2 | Planned & Tracked | The control is documented and performed, but locally and inconsistently. |
| 3 | Well Defined | Standardised, documented organisation-wide processes are consistently followed. |
| 4 | Quantitatively Controlled | The control is measured with metrics and managed quantitatively. |
| 5 | Continuously Improving | Metrics drive continuous, proactive optimisation of the control. |
Setting target levels
Most organisations do not target level 5 everywhere; that is rarely cost-justified. A common pattern is level 3 (Well Defined) as the baseline for regulated controls, with level 4 or 5 reserved for the highest-risk domains such as Identity & Access Management, Incident Response and Data Privacy.
Assessment and audit approach
An SCF assessment is a structured, evidence-driven exercise. The following ordered steps describe a typical engagement.
- Confirm scope: agree the boundary, applicable authoritative sources and the tailored SCF control set.
- Confirm target maturity: agree the target SP-CMM level for each domain or control.
- Gather documentation: collect policies, standards, procedures and the control-mapping matrix.
- Assess design: evaluate whether each control is adequately designed to meet its objective and target level.
- Assess operating effectiveness: sample evidence over a period to confirm the control operates as designed.
- Score maturity: rate each control against the SP-CMM and record the gap to target.
- Document findings: log non-conformities, observations and root causes with risk ratings.
- Agree remediation: capture corrective actions, owners and due dates in a remediation plan.
- Report and attest: produce the assessment report, maturity scorecard and mapping to external certifications.
- Re-test and close: verify remediation and close findings, feeding into continuous monitoring.
Evidence request list
- Governance: programme charter, board minutes, policies, standards, roles and responsibilities.
- Risk: risk methodology, risk register, treatment plans, risk-acceptance records.
- Asset & configuration: asset inventory/CMDB, hardening baselines, configuration-compliance scans.
- Identity & access: identity register, MFA enforcement, access reviews, PAM logs.
- Data protection: classification policy, RoPA, DPIAs, DLP config, retention and disposal records.
- Cryptography: crypto standards, key-management procedures, TLS/at-rest configuration.
- Monitoring & incident: logging standards, SIEM config, incident tickets, breach-notification records.
- Resilience: BIA, RTO/RPO register, backup and restore-test evidence, BC/DR exercise reports.
- Vulnerability: scan reports, remediation SLAs, patch records, penetration-test reports.
- Third party: vendor due-diligence, contracts/DPAs, supplier attestations and reviews.
- People: training completion records, phishing results, joiner/leaver and screening records.
- Assurance: internal audit reports, prior assessments, POA&M/remediation trackers.
Roles and responsibilities
| Role | Responsibilities |
|---|
| Board / Executive sponsor | Approve the programme, allocate budget, own residual risk and set risk appetite. |
| CISO | Own the security programme, control design, and SP-CMM target-setting. |
| Data Protection Officer / Privacy lead | Own the PRI and privacy-related controls, DSR handling and DPIAs. |
| GRC / Compliance manager | Maintain the obligations register, SCF mappings and evidence repository. |
| Control owners | Implement and operate assigned SCF controls and produce evidence. |
| IT / Engineering teams | Deploy technical controls, baselines and monitoring. |
| Internal audit | Independently assess control design and operating effectiveness. |
| Third-party / vendor manager | Run supplier due diligence and ongoing oversight (TPM domain). |
KPIs / metrics to track
- Average SP-CMM maturity score per domain and trend over time.
- Percentage of applicable SCF controls implemented versus target.
- Number and ageing of open control gaps / findings.
- MFA and privileged-access coverage percentages.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for incidents.
- Vulnerability remediation within SLA (percentage by severity).
- Patch compliance rate across critical systems.
- Percentage of staff completing awareness training and phishing failure rate.
- Data-subject request fulfilment within statutory deadlines.
- Percentage of critical suppliers with current risk assessments and DPAs.
- Backup restore-test success rate and RTO/RPO adherence.
Readiness checklist
- Executive sponsorship secured and governance established.
- Programme scope, boundary and applicable authoritative sources documented.
- Current SCF catalogue downloaded and tailored to applicable controls.
- Target SP-CMM level set for each domain and control.
- Control-to-obligation mapping matrix completed.
- Gap assessment performed and remediation backlog prioritised.
- Policies and standards written, approved and published.
- Technical controls (IAM, monitoring, encryption, endpoint) deployed.
- Evidence repository established with control owners assigned.
- Third-party risk assessments and DPAs in place for critical suppliers.
- Incident response and BC/DR plans tested within the last year.
- Internal assessment against SP-CMM completed and findings tracked.
- Attribution honoured for SCF use and licence terms observed.
Common gaps and findings
- Treating the SCF as a checklist without setting or measuring SP-CMM maturity levels.
- Incomplete obligations register, so applicable controls are wrongly excluded.
- Stale or missing asset inventory undermining every downstream control.
- MFA and privileged-access controls partially deployed, leaving high-value accounts exposed.
- Backups not tested by restoration, so recovery capability is unproven.
- Vulnerability remediation SLAs undefined or routinely breached without exceptions.
- Third-party oversight limited to onboarding, with no periodic reassessment.
- Privacy controls (RoPA, DPIAs, DSR handling) weak despite regulatory exposure.
- Evidence not retained or not tied to specific controls, causing audit friction.
- Failure to update the tailored control set when a new SCF release or regulation lands.
- Attribution requirement of the CC BY-ND licence overlooked in redistributed materials.
SCF mapped to other frameworks
The SCF's principal value is its extensive cross-mapping to authoritative sources. The table below illustrates how SCF domains relate to widely used frameworks and regulations. These are illustrative alignments; the authoritative, control-level mappings are maintained in the official SCF spreadsheet.
| External framework / regulation | How the SCF relates |
|---|
| ISO/IEC 27001 / 27002 | SCF domains map to Annex A control themes; a single SCF implementation supports ISMS certification. |
| NIST Cybersecurity Framework (CSF) | SCF controls map to the CSF functions (Identify, Protect, Detect, Respond, Recover, Govern). |
| NIST SP 800-53 | SCF controls trace to 800-53 control families for federal and moderate/high baselines. |
| NIST SP 800-171 / CMMC | SCF maps to CUI protection requirements supporting CMMC readiness. |
| PCI DSS | SCF network, crypto, access and monitoring domains align to PCI DSS requirements for cardholder data. |
| SOC 2 (TSC) | SCF supports the Trust Services Criteria for security, availability, confidentiality and privacy. |
| EU GDPR | SCF PRI and DCH domains map to GDPR principles, data-subject rights and transfer rules. |
| India DPDP Act 2023 | SCF privacy controls support Data Fiduciary obligations and data-principal rights. |
| EU AI Act / AI governance | SCF AIT domain aligns to AI risk management and oversight expectations. |
| CIS Controls | SCF technical domains map to CIS safeguards and implementation groups. |
How CyberSigma helps
CyberSigma helps organisations adopt the Secure Controls Framework end to end. Our CERT-In empanelled and PCI QSA-qualified assessors define your programme scope, build the obligations register, tailor the SCF control set and set defensible SP-CMM target levels. We run the gap assessment, drive remediation, author your policy and standards library, and assemble an audit-ready evidence repository. Because the SCF maps to over 250 sources, we then help you convert that single control base into multiple external outcomes — ISO/IEC 27001 certification, SOC 2 readiness, PCI DSS validation, and GDPR/DPDP privacy compliance — without duplicating effort. Talk to CyberSigma to turn the SCF into a measurable, defensible and continuously improving security and privacy programme.
