What is Cyber Security Architecture?
Getting security right at the start of development helps to create systems that are easier to secure and can reduce the need for any costly rework in the future.
3 April 2023
Get the latest cyber news and updates straight to your inbox.
A quick-reference tool for boards, compliance leads, and developers The key areas covered by the DSIT Software Security & Cyber Governance Codes of Practice. Use this checklist to spot your gaps and prepare to align.
The UK Department for Science, Innovation and Technology (DSIT) has introduced voluntary Codes of Practice that mark a significant shift in regulatory expectations. Cyber risk is no longer an IT problem—it is a strategic board-level responsibility.
While currently voluntary, these codes are rapidly becoming the standard for due diligence in supply chains, RFPs, and regulatory audits. Use this checklist to evaluate your current posture and identify gaps before your clients or regulators do.
This code shifts the focus from technical controls to strategic oversight. It ensures that the board has ownership of cyber risk, treating it with the same rigorous governance as financial or legal risk.
☐ Asset Identification: Have we formally identified and valued our critical assets (data, IP, physical infrastructure)?
☐ Executive Ownership: Is there a named Board Member or Senior Executive explicitly responsible for cyber risk?
☐ Risk Appetite: Has the Board defined a clear “Cyber Risk Appetite” statement?
☐ Supply Chain: Are we assessing our suppliers’ cyber posture against our own risk appetite?
☐ Strategic Alignment: Is our cyber strategy integrated directly with the wider business strategy?
☐ Adequate Resourcing: Is the security budget and headcount sufficient to meet the strategy defined by the Board?
☐ “Trust but Verify”: Do we have independent audit mechanisms (internal or external) to prove controls are working?
☐ Formal Reporting: Does the CISO provide a formal risk status report to the Board at least quarterly?
☐ Just Culture: Do we foster a “No Blame” environment that encourages immediate incident reporting?
☐ Specific Training: Is cyber training conducted annually and tailored to specific roles (not just generic videos)?
☐ The Plan: Do we have an up-to-date, documented Incident Response (IR) plan?
☐ Tabletop Exercises: Does the Board participate in regular IR simulations to test decision-making under pressure?
☐ Recovery Focus: Does our plan prioritize business continuity and recovery time objectives (RTO)?
A breakdown of the Cyber Governance Code of Practice. The code shifts cyber responsibility from IT to the board. What that means and what you can do now.
This code demands a “Secure by Design” approach. It requires security to be embedded throughout the entire software development lifecycle (SDLC), rather than treating security as a testing phase at the end.
☐ Framework Adoption: Do we follow a recognized secure development framework (e.g., OWASP ASVS, NIST SSDF)?
☐ Threat Modeling: Is threat modeling a mandatory step during the design phase of new features?
☐ Secure by Default: Is the product secure out-of-the-box (e.g., forced MFA, no default passwords)?
☐ Rigorous Testing: Do we perform both automated scanning (SAST/DAST) and manual penetration testing before major releases?
☐ Pipeline Hardening: Is our build environment strictly isolated from development and testing environments?
☐ Access Control: Is Multi-Factor Authentication (MFA) enforced for every developer and admin accessing the build pipeline?
☐ Audit Trails: Are all changes to the build environment and code repositories logged and immutable?
☐ Integrity Checks: Do we provide mechanisms (like hash checks or code signing) so customers can verify software integrity?
☐ Dependency Management: Do we have an automated process to track and patch third-party libraries (SBOM)?
☐ Disclosure Policy: Do we have a publicly accessible vulnerability disclosure policy?
☐ Lifecycle Transparency: Is the support lifecycle of our software clearly communicated to customers?
☐ End of Life (EOL): Do we commit to providing at least 12 months’ notice before a product goes EOL?
☐ Incident Notification: Is there a defined SLA and process to notify customers of security incidents?
An in-depth view of the Software Security Code of Practice. Why it exists, who it affects, and how your organisation can align.
The UK Government expects businesses to “Comply or Explain.” If you checked “No” to any of the items above, your organization may be exposed to regulatory scrutiny or commercial disadvantage.
Need a formal gap analysis?
FoxTech can help you translate these codes into a roadmap for your Board and Development teams.
Get a compliance report for regulations like NIS2, DORA, and GDPR.
Getting security right at the start of development helps to create systems that are easier to secure and can reduce the need for any costly rework in the future.
Cybersecurity is an essential aspect of today’s increasingly digital business landscape. As organisations rely more heavily on technology, they face a growing number of threats from hackers and cybercriminals.
This case study demonstrates how FOXTECH helped a client achieve Cyber Essentials certification, win government contracts, and reassure their customers about their security standards