Statement of Applicability (SoA) Generator
Identify the Secure by Design controls and associated risks that apply to your project, based on the data you handle, the people you serve and the technologies you use.
Project details
Capture the metadata that will appear on the front page of your Statement of Applicability.
How to use this tool
- 1. Enter project details.
- 2. Select the data types your service handles.
- 3. Identify your stakeholders.
- 4. Identify the technologies in scope.
- 5. Review the recommended controls, set priority and capture risks.
- 6. Export to Word, PDF or CSV.
All data is held in your browser. Nothing is sent to a server.
Data types in scope
Tick every data category your service will create, process, store or share. Each selection drives the list of applicable controls and the legislation that applies.
Stakeholders
Tick every group that will interact with the service or whose data is processed by it.
Technologies and architecture
Tick every technology component or pattern that is part of the design.
Applicable controls and risk register
Each control below has been identified as applicable to your selected data, stakeholders and technologies. Open a control to see its mapping to Secure by Design, NCSC CAF v4.0 and the NIST SP 800-53, and capture inherent and residual risk.
Lower-sensitivity service. The baseline is limited to controls required of every service regardless of context.
How this tier was reached
| Driver | Highest-rated selection | Weight |
|---|---|---|
| Nothing selected yet - the baseline is at its minimum. | ||
| Peak 0 + breadth 0 + classification 0 | score 0 | |
Scoring uses the highest-sensitivity selection in each dimension rather than a total, so one category of highly sensitive data raises the tier regardless of how much routine data sits beside it. Breadth adds 1 for each dimension scoring 4 or more.
11 controls match
Event Logging
Decide deliberately what to log, driven by what you would need to answer during an investigation. Logging is the evidence base every other assurance claim rests on, which is why it sits at tier 1.
Assessment objective (6 determination statements)
- [event types] that the system is capable of logging are identified in support of the audit logging function
- The event logging function is coordinated with other organisational entities requiring audit-related information to guide and inform the selection criteria for events to be logged
- [event types (subset of AU-02_ODP[01])] are specified for logging within the system
- The specified event types are logged within the system [frequency or situation]
- A rationale is provided for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents
- The event types selected for logging are reviewed and updated [frequency]
- Secure by Design
- SbD-5 – Build in detect and respond security; SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- C1.a Sources and Tools for Logging and Monitoring
- Mapping confidence
- Strong
- CAF outcomes
- C1.a
- NIST reference
- AU-2 – Audit and Accountability
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Detect
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0; UK GDPR
- Example threats
- An incident cannot be reconstructed because the relevant events were never logged; Access to personal data is not logged, so misuse is undetectable
- MITRE techniques
- T1685.005 Disable or Modify Tools: Clear Windows Event Logs; T1530 Data from Cloud Storage
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Control Assessments
Independent assessment of whether the controls actually work, distinct from the team's own view. CAF v4.0 moved assurance to A2.c specifically to stop it being answered with 'we have a policy'.
Assessment objective (9 determination statements)
- An appropriate assessor or assessment team is selected for the type of assessment to be conducted
- A control assessment plan is developed that describes the scope of the assessment, including controls and control enhancements under assessment
- A control assessment plan is developed that describes the scope of the assessment, including assessment procedures to be used to determine control effectiveness
- A control assessment plan is developed that describes the scope of the assessment, including the assessment environment
- A control assessment plan is developed that describes the scope of the assessment, including the assessment team
- A control assessment plan is developed that describes the scope of the assessment, including assessment roles and responsibilities
- The control assessment plan is reviewed and approved by the authorising official or designated representative prior to conducting the assessment
- Controls are assessed in the system and its environment of operation [assessment frequency] to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting established security requirements
- …and 3 further determination statements in SP 800-53A.
- Secure by Design
- SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- A2.c Assurance
- Mapping confidence
- Strong
- CAF outcomes
- A2.c
- NIST reference
- CA-2 – Assessment, Authorization, and Monitoring
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Identify
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0; GDS Service Standard
- Example threats
- Assurance is self-asserted by the team that built the service
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Plan of Action and Milestones
A plan of action with milestones for every weakness not yet fixed, so that known gaps are managed rather than forgotten.
Assessment objective (2 determination statements)
- A plan of action and milestones for the system is developed to document the planned remediation actions of the organisation to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system
- Existing plan of action and milestones are updated [frequency] based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities
- Secure by Design
- SbD-9 – Embed continuous assurance; SbD-10 – Make changes securely
- NCSC CAF v4.0
- A2.c Assurance
- Mapping confidence
- Strong
- CAF outcomes
- A2.c
- NIST reference
- CA-5 – Assessment, Authorization, and Monitoring
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Identify
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0
- Example threats
- Accepted weaknesses have no expiry and quietly become permanent
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Continuous Monitoring
Continuous monitoring of control effectiveness, so the risk owner has current evidence rather than an annual snapshot. This is the control that turns a Statement of Applicability from a statement of intent into an assurance argument.
Assessment objective (9 determination statements)
- A system-level continuous monitoring strategy is developed
- System-level continuous monitoring is implemented in accordance with the organisation-level continuous monitoring strategy
- System-level continuous monitoring includes establishment of the following system-level metrics to be monitored: [system-level metrics]
- System-level continuous monitoring includes established [frequencies] for monitoring
- System-level continuous monitoring includes established [frequencies] for assessment of control effectiveness
- System-level continuous monitoring includes ongoing control assessments in accordance with the continuous monitoring strategy
- System-level continuous monitoring includes ongoing monitoring of system and organisation-defined metrics in accordance with the continuous monitoring strategy
- System-level continuous monitoring includes correlation and analysis of information generated by control assessments and monitoring
- …and 3 further determination statements in SP 800-53A.
- Secure by Design
- SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- A2.c Assurance; C1.a Sources and Tools for Logging and Monitoring
- Mapping confidence
- Strong
- CAF outcomes
- A2.c, C1.a
- NIST reference
- CA-7 – Assessment, Authorization, and Monitoring
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Detect
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0
- Example threats
- Controls degrade silently between annual assessments
- MITRE techniques
- T1078 Valid Accounts
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Penetration Testing
Independent penetration testing before live and after significant change, with findings tracked to closure. An IT health check report with open highs is not evidence of assurance.
Assessment objective
- Penetration testing is conducted [frequency] on [system(s) or system components]
- Secure by Design
- SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- A2.c Assurance; B4.d Vulnerability Management
- Mapping confidence
- Strong
- CAF outcomes
- A2.c, B4.d
- NIST reference
- CA-8 – Assessment, Authorization, and Monitoring
- NIST baseline
- HIGH
- Significance weighting
- 6
- NIST CSF function
- Identify
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0; GDS Service Standard
- Example threats
- Testing is scoped to exclude the components most likely to be vulnerable; Report is filed without a remediation plan
- MITRE techniques
- T1190 Exploit Public-Facing Application; T1213 Data from Information Repositories
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Contingency Plan Testing
Exercise the contingency plan on a schedule, and record what the exercise changed.
Assessment objective (5 determination statements)
- The contingency plan for the system is tested [frequency]
- [tests] are used to determine the effectiveness of the plan
- [tests] are used to determine the readiness to execute the plan
- The contingency plan test results are reviewed
- Corrective actions are initiated, if needed
- Secure by Design
- SbD-6 – Design flexible architectures; SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- B5.a Resilience Preparation; D1.c Testing and Exercising
- Mapping confidence
- Strong
- CAF outcomes
- B5.a, D1.c
- NIST reference
- CP-4 – Contingency Planning
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Recover
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0
- Example threats
- Testing confirms the plan is followed rather than whether it works
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Incident Response Testing
Test the response plan through exercises, including scenarios where the primary responders are unavailable.
Assessment objective
- The effectiveness of the incident response capability for the system is tested [frequency] using [tests]
- Secure by Design
- SbD-5 – Build in detect and respond security; SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- D1.c Testing and Exercising
- Mapping confidence
- Strong
- CAF outcomes
- D1.c
- NIST reference
- IR-3 – Incident Response
- NIST baseline
- MODERATE
- Significance weighting
- 8
- NIST CSF function
- Respond
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0
- Example threats
- Plan has never been rehearsed and fails on first contact
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Vulnerability Monitoring and Scanning
Regular vulnerability scanning with a defined remediation clock by severity. The clock matters more than the scan: an unactioned finding is not a control.
Assessment objective (9 determination statements)
- Systems and hosted applications are monitored for vulnerabilities [frequency and/or randomly in accordance with…] and when new vulnerabilities potentially affecting the system are identified and reported
- Systems and hosted applications are scanned for vulnerabilities [frequency and/or randomly in accordance with…] and when new vulnerabilities potentially affecting the system are identified and reported
- Vulnerability monitoring tools and techniques are employed to automate parts of the vulnerability management process by using standards for enumerating platforms, software flaws, and improper configurations
- Vulnerability monitoring tools and techniques are employed to facilitate interoperability among tools and to automate parts of the vulnerability management process by using standards for formatting checklists and test procedures
- Vulnerability monitoring tools and techniques are employed to facilitate interoperability among tools and to automate parts of the vulnerability management process by using standards for measuring vulnerability impact
- Vulnerability scan reports and results from vulnerability monitoring are analysed
- Legitimate vulnerabilities are remediated [response times] in accordance with an organisational assessment of risk
- Information obtained from the vulnerability monitoring process and control assessments is shared with [personnel or roles] to help eliminate similar vulnerabilities in other systems
- …and 1 further determination statements in SP 800-53A.
- Secure by Design
- SbD-9 – Embed continuous assurance; SbD-5 – Build in detect and respond security
- NCSC CAF v4.0
- B4.d Vulnerability Management; C2.a Threat Hunting
- Mapping confidence
- Strong
- CAF outcomes
- B4.d, C2.a
- NIST reference
- RA-5 – Risk Assessment
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Detect
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0; UK GDPR
- Example threats
- Findings accumulate in a backlog with no owner and no deadline; Scanning covers infrastructure but not application dependencies
- MITRE techniques
- T1595 Active Scanning; T1190 Exploit Public-Facing Application
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Developer Testing and Evaluation
Security testing within development, automated in the pipeline so that it runs on every change rather than at a milestone.
Assessment objective (9 determination statements)
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to develop a plan for ongoing security assessments
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to implement a plan for ongoing security assessments
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to develop a plan for privacy assessments
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to implement a plan for ongoing privacy assessments
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to perform [unit, integration, system or regression] testing/evaluation [frequency to conduct] at [depth and coverage]
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to produce evidence of the execution of the assessment plan
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to produce the results of the testing and evaluation
- The developer of the system, system component, or system service is required at all post-design stages of the system development life cycle to implement a verifiable flaw remediation process
- …and 1 further determination statements in SP 800-53A.
- Secure by Design
- SbD-9 – Embed continuous assurance; SbD-10 – Make changes securely
- NCSC CAF v4.0
- A4.b Secure Software Development and Support; B4.d Vulnerability Management
- Mapping confidence
- Strong
- CAF outcomes
- A4.b, B4.d
- NIST reference
- SA-11 – System and Services Acquisition
- NIST baseline
- MODERATE
- Significance weighting
- 8
- NIST CSF function
- Identify
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0
- Example threats
- Testing is a pre-release activity, so defects are found when they are most expensive
- MITRE techniques
- T1190 Exploit Public-Facing Application; T1059.007 Command and Scripting Interpreter: JavaScript
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Flaw Remediation
Remediate flaws on a defined clock, with an emergency path for actively exploited vulnerabilities.
Assessment objective (9 determination statements)
- System flaws are identified
- System flaws are reported
- System flaws are corrected
- Software updates related to flaw remediation are tested for effectiveness before installation
- Software updates related to flaw remediation are tested for potential side effects before installation
- Firmware updates related to flaw remediation are tested for effectiveness before installation
- Firmware updates related to flaw remediation are tested for potential side effects before installation
- Security-relevant software updates are installed within [time period] of the release of the updates
- …and 2 further determination statements in SP 800-53A.
- Secure by Design
- SbD-10 – Make changes securely; SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- B4.d Vulnerability Management
- Mapping confidence
- Strong
- CAF outcomes
- B4.d
- NIST reference
- SI-2 – System and Information Integrity
- NIST baseline
- LOW
- Significance weighting
- 10
- NIST CSF function
- Protect
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0; UK GDPR
- Example threats
- A known exploited vulnerability waits for the next monthly release window
- MITRE techniques
- T1190 Exploit Public-Facing Application; T1210 Exploitation of Remote Services
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Provenance
Provenance for the components in the service, in practice a software bill of materials kept current. Without one, responding to a newly disclosed dependency vulnerability starts with days of discovery.
Assessment objective (3 determination statements)
- Valid provenance is documented for [systems, system components, and associated d…]
- Valid provenance is monitored for [systems, system components, and associated d…]
- Valid provenance is maintained for [systems, system components, and associated d…]
- Secure by Design
- SbD-2 – Source secure technology products; SbD-9 – Embed continuous assurance
- NCSC CAF v4.0
- A4.a Supply Chain; A4.b Secure Software Development and Support
- Mapping confidence
- Strong
- CAF outcomes
- A4.a, A4.b
- NIST reference
- SR-4 – Supply Chain Risk Management
- Significance weighting
- 3
- NIST CSF function
- Identify
- Legislation / policy
- NCSC Cyber Assessment Framework v4.0
- Example threats
- A critical dependency vulnerability is disclosed and no-one can say whether it is in use
- MITRE techniques
- T1195.001 Supply Chain Compromise: Compromise Software Dependencies and Development Tools; T1588.006 Obtain Capabilities: Vulnerabilities
Risk assessment
Each scenario states the asset at stake, the threat event, the vulnerability it exploits and the direct consequence. Adapt the wording to this service before relying on it.
Assurance and evidence
How a risk owner would know this control is working. Required to demonstrate Secure by Design principle 9.
Review and export
Statement of Applicability ready
Export options
Generate a printable Statement of Applicability or a data file that can be imported into a project risk register.
Document preview
Configuration map
A traceability matrix of how scope becomes controls. Read across a row to see what a selection brings in; read down a column to see what put a control there. Generated live from the same gate, tier and weighting tables the tool uses to set defaults.
Secure by Design
What this tool maps to, what it does not cover, and where it fits in Secure by Design delivery.