Show UK Government your delivery is Secure by Design.

What gov.uk says. The Senior Responsible Officer is accountable for cyber security risk on the digital service. A Security Working Group oversees and co-ordinates day-to-day activity, with all decisions counter-signed by the SRO. An independent security consultant should sit within the SyWG so the team is not assessing its own work. The risk appetite is agreed in writing and reviewed when expected risk changes.

What Secruna captures via the checklist. The SRO appointment in writing (with the supporting letter or PID minute attached), the agreed risk appetite signed off by the SRO, the SyWG terms of reference and meeting cadence, the independent security consultant’s membership, the RACI matrix mapping roles to each Secure by Design activity, and the consultation record with the information owners for the data the service processes. Each item carries an evidence-examples block listing the artefacts gov.uk recommends, so the delivery team collects a signed letter, not a free-text claim.

See this in your dashboard at: /checklists/secure-by-design#create_responsibility_for_cyber_security_risk with per-item answers, evidence attachments and the SRO sign-off cadence surfaced.

What gov.uk says. When choosing third-party products, components and services, evaluate their security posture before adoption and continue to manage the risk through the service’s life. Procurement and supply-chain decisions are part of the security envelope, not separate from it. Open-source dependencies count as technology products under this principle and need continuous tracking. End-of-life components must be replaced before they go unsupported.

What Secruna captures via the checklist. The documented third-party product risks (with an SBOM and per-component risk annotation), the security evidence obtained from each supplier (ISO 27001, SOC 2 Type II, Cyber Essentials Plus), the security-requirements clauses written into procurement contracts and statements of work, the open-source dependency tracker, the supplier incident-notification clauses, and the technology roadmap showing supported- until dates with a replacement plan for components within 12 months of EoL. Each item lifts the gov.uk recommended evidence into a dedicated checklist row so a procurement officer sees the same vocabulary as the SRO.

See this in your dashboard at: /checklists/secure-by-design#source_secure_technology_products with per-item answers, evidence attachments and the supplier review cadence surfaced.

What gov.uk says. Identify, analyse and evaluate the cyber security risks of the service so that decisions about controls, architecture and assurance are informed by where the real threats lie. Use a recognised risk-assessment framework — gov.uk lists ISO, NCSC and NIST methods, with NIST 800-30 the standard MoD pick. Refresh the assessment as circumstances change rather than treating it as a once-and-done exercise.

What Secruna captures via the checklist. The chosen risk-assessment framework (with the standard cited), the threat-modelling exercise and its outputs, the documented risks with severity / likelihood / treatment-decision per risk, the SRO-approved tolerance bands, the refresh cadence, and the trigger conditions that force a re-run (architecture change, scope change, significant incident). The Confidence Profile Report shows refresh-overdue items in the §3 outstanding list so the SRO sees stale risk data alongside missing evidence.

See this in your dashboard at: /checklists/secure-by-design#adopt_a_risk_driven_approach with per-item answers, the chosen risk framework, and the refresh-overdue flag per item.

What gov.uk says. Security controls that users find unusable are routinely circumvented, which leaves the service no safer than if the control had not been imposed. Design controls with the user experience in mind, validate them with real users, and measure adoption rather than assuming compliance once the policy is published.

What Secruna captures via the checklist. The user research that informed each significant control, the usability testing notes for the control touch-points (logins, MFA prompts, access-request flows), the adoption-rate metrics for the deployed control set, the support-desk ticket volumes attributable to security friction, and the control- reduction or simplification register where a control was retired because it was driving non-compliant behaviour. The connector signal cross-references the policy claim against the actual MFA enrolment rate per identity, so a “yes” on policy is not a “yes” on usable adoption unless the metric backs it up.

See this in your dashboard at: /checklists/secure-by-design#design_usable_security_controls with per-item answers and the connector signal cross- referencing user adoption metrics.

What gov.uk says. Build the ability to detect and respond to security events into the service from the start, rather than bolting it on after launch. Logging, alerting and incident-response capabilities must be in place by beta, exercised by live, and maintained through retirement. An incident-response plan that has only been written, not exercised, is a liability rather than a control.

What Secruna captures via the checklist. The audit-log retention configuration per major connector (Microsoft 365, Azure, Google Workspace), the alert-routing destinations and on-call cover, the incident-response plan document with its exercise cadence, the lessons-learned register from the most recent exercise, the escalation path to the department’s SOC or shared SOC service, and the integration with NCSC reporting workflows where applicable. The audit trail in §5 of the Confidence Profile Report records every response edit so the spend control reviewer sees the platform actively collecting evidence rather than rendering a once-and- done snapshot.

See this in your dashboard at: /checklists/secure-by-design#build_in_detect_and_respond_security with per-item answers and the incident-response exercise cadence flagged.

What gov.uk says. Threats evolve faster than re-architecture cycles. Design the service so a new control can be slotted in, an old one swapped out, and a discovered weakness mitigated without rebuilding the whole system. Modular boundaries, well-documented integration contracts and a clean separation of identity, data and execution layers all support this principle.

What Secruna captures via the checklist. The architecture decision records (ADRs) that document the modularity choices, the integration contracts between major service boundaries, the identity and data abstraction layers, the dependency-injection points where new controls can be inserted, the dependency-version policy that keeps libraries upgradeable, and the architecture review cadence. Items with a heavy technical-debt signal surface as outstanding even when answered “yes” on policy, because flexibility is a property of the codebase, not of the architecture document.

See this in your dashboard at: /checklists/secure-by-design#design_flexible_architectures with per-item answers and the architecture review cadence surfaced.

What gov.uk says. Minimise the parts of the service exposed to attack. Every public endpoint, every open port, every privileged identity and every third-party integration adds to the attack surface and has to be justified. The principle is best-effort minimisation, not zero — but the burden of proof for keeping an exposure sits with the delivery team, not the SRO.

What Secruna captures via the checklist. The inventory of public endpoints with the business-justification per endpoint, the open-port inventory with the same justification, the privileged- identity register and the access-review cadence, the third-party integration register with the data each integration accesses, and the exception register where a control is reduced and why. Connector signals cross- reference the policy claim against the live state — an endpoint marked decommissioned that still resolves on DNS surfaces as an outstanding item even when policy says it has been removed.

See this in your dashboard at: /checklists/secure-by-design#minimise_the_attack_surface with per-item answers and the connector signal cross- referencing live exposure state.

What gov.uk says. Assume any individual control may fail and design multiple independent defences so a breach of one is contained by the next. Defence in depth covers identity, network, application and data layers; a service that gates everything on perimeter access has not designed for the day the perimeter is breached.

What Secruna captures via the checklist. The identity layer’s controls (MFA, conditional access, just-in-time elevation), the network layer (segmentation, deny-by-default boundaries, egress filtering), the application layer (WAF, input validation, output encoding, secret management), the data layer (encryption at rest, encryption in transit, backup integrity), and the cross-layer dependencies a breach would need to compromise to reach the data. Each item carries a redundancy note describing the next layer’s defence, so a “yes” is evidence of layering rather than a claim of a single strong control.

See this in your dashboard at: /checklists/secure-by-design#defend_in_depth with per-item answers and the cross-layer dependency chain surfaced.

What gov.uk says. Assurance is a continuous activity — not a once-a-year exercise. Vulnerability scanning, penetration testing, compliance checks, control-effectiveness measurement and SyWG reviews all need to run on a documented cadence so the SRO can rely on a current Confidence Profile rather than one based on stale data. Quarterly refresh of the Self-Assessment Tracker is the floor, not the ceiling.

What Secruna captures via the checklist. The vulnerability-scanning cadence with the last-scan date per asset, the penetration-test schedule with findings tracked through to closure, the compliance-check cadence (cyber posture, encryption, access reviews), the control-effectiveness metrics (MFA enrolment, patch compliance, log-coverage), and the SyWG review schedule with the last-meeting date per programme. Items overdue against their cadence surface as outstanding in the Confidence Profile Report regardless of the answer the team last recorded.

See this in your dashboard at: /checklists/secure-by-design#embed_continuous_assurance with per-item answers and the cadence-overdue flag per activity.

What gov.uk says. Changes to the service — code, configuration, infrastructure, third-party integration — must flow through a change-control process that re-evaluates security impact before the change lands. CI/CD pipelines need security gates; configuration changes need peer review; emergency patches need a documented exception path that does not skip the review entirely.

What Secruna captures via the checklist. The change-management policy with the security-review gate, the CI/CD pipeline configuration showing the security checks (SAST, SCA, secret scanning, license scanning, IaC linting), the peer-review enforcement on the source-control branch protections, the configuration-change audit trail across the major connectors, the emergency-change exception register, and the post-change review cadence. Items where the connector signal contradicts the policy claim — for example a branch protection that allows force-pushes despite a policy that forbids them — surface as outstanding regardless of the answer the team recorded.

See this in your dashboard at: /checklists/secure-by-design#make_changes_securely with per-item answers and the connector signal cross- referencing the live change-control state.