On more than a few occasions we’ve been asked the same deceptively simple question by delivery teams: “What are the right security controls for our build and deployment?” It’s a fair question—and it’s often asked late in the day, when pressure is rising and teams are trying to ship.
In theory, the path is well understood. Pick a framework, understand your risks (based on your threats and vulnerabilities), and tailor controls to the context so you get the right outcomes for the least cost and friction.
In practice, that maturity model can be out of step with delivery reality. Teams are trying to move quickly, environments are evolving, and “do something now” can feel more urgent than building a coherent risk approach (familiar?). As a result, we often see organisations land in one of two camps:
-
A mature security posture at the organisational level—strategy, policies, an enforced ISMS—but limited connection to the practical controls and patterns teams need day-to-day in engineering environments.
-
A technically-driven security posture—baseline controls and standards (CISA, NIST, CIS, OWASP, etc.) adopted because they are recognisable and audit-friendly—sometimes without a clear understanding of why each control matters or what benefit it delivers. It meets a compliance test and supports “due care”, but can become a checklist rather than a risk-informed approach.
Which pattern emerges often depends on who “owns” cyber risk in the organisation: the CRO, CSO, CISO or CTO. And that matters, because each role typically emphasises different outcomes—assurance, operational resilience, compliance, or delivery speed.
Unfortunately, cyber security is still too often framed as a “tech problem”: buy something, configure it, and ask the dev team to switch it on. Experience shows the reality is more nuanced. Administrative controls—training, joiners/movers/leavers, peer review, access governance, assurance checkpoints—are often better value and more consistently effective than new tooling. But the right balance comes back to the same core point: understanding the risk and choosing actions that reduce it in a measurable, proportionate way.
Securing Services, Solutions and Data
A useful reset is to stop thinking purely in terms of “securing an application”. In regulated, confidential or sensitive environments, what we are really trying to secure is a service or solution—including the data it processes, stores, and exposes.
That data may be customer, citizen, patient or corporate data, and it exists in multiple states:
- At rest (stored in databases, files, backups, logs)
- In transit (across networks and integrations)
- In use (in memory, in processing pipelines, in analytic services)
Controls need to protect the service end-to-end—not just the code. That’s why frameworks can feel confusing: each one views risk from a different angle and at a different level of abstraction. Many overlap, which is reassuring, but it can also create uncertainty about what to adopt, what to prioritise, and how to translate “framework language” into real-world engineering controls.
In this guide we compare widely used approaches—ISO 27000, NIST and CIS—through the lens of digital services and cloud delivery, focusing on how they relate to application security across the software delivery lifecycle. We then touch on complementary governance and assurance perspectives (COBIT, CMMI, OWASP, NCSC guidance and others) that help teams implement security as an operating model, not just a technical checklist.
Confidentiality, Integrity and Availability
Most security controls ultimately exist to reduce risk to Confidentiality, Integrity and Availability (CIA)—of services, solutions and their data. The vulnerabilities you need to mitigate depend on context: the sensitivity of the data, the threat landscape, the service model, and your risk tolerance.
Healthcare citizen data, financial payment information, and identity services all require strong protection. But they may be governed through different standards, compliance regimes, and assurance models—even when many of the underlying controls look similar.
Public and private sector guidance reinforces that point. In the UK, the NCSC provides application security guidance and principles (for example, Application Development Guidance: Introduction). In the US and globally, NIST offers structured control sets and reference models (for example, the NIST Cybersecurity Framework). Sector and regulatory standards add further constraints: PCI-DSS for payment handling, HIPAA in US healthcare, NHS Digital’s Data Security and Protection Toolkit, and data protection legislation such as GDPR.
The message is not “use everything”. It is: use the right combination, aligned to risk and governance, and implement it in a way teams can actually sustain.
What's the difference. ?
Frameworks differ in how they help you select, implement, and measure controls.
ISO/IEC 27001 is the internationally recognised standard for building an Information Security Management System. It focuses heavily on risk management, roles, policies and procedures—more of the “what and governance” than the “how and engineering detail”. It is valuable for organisational assurance, but teams often need additional guidance to translate it into concrete technical practices.
NIST 800-53 provides a comprehensive catalogue of security controls—technical, procedural and physical—originally designed for US federal systems but widely used as a reference internationally. The NIST 800-53B baselines define control sets by assurance level (low/moderate/high), which can help teams tailor controls to risk. The NIST Cybersecurity Framework offers a more digestible, industry-friendly approach, and is often used as a practical starting point.
The CIS Critical Security Controls (v8) are a set of measurable best practices designed to protect critical assets. They are technically specific, widely adopted, and often attractive when teams want a clear baseline that supports “due care” and audit confidence. Application-focused guidance is captured in CIS Control 16 and its safeguards.
All three are relevant to application delivery, but implementing “all controls from all frameworks” is rarely sensible. There is substantial overlap, and the right choice depends on your operating model, your risk approach, and the maturity of your assurance processes. The mapping between frameworks helps: CIS provides useful crosswalks to NIST 800-53 Rev. 5 and ISO/IEC 27002:2022, which is reassuring if you need multiple viewpoints to align.
ISO27000
Below is a summary of ISO27000-aligned themes that commonly relate to securing an application lifecycle. In practice these sit within a wider ISMS, but they also make a useful design assurance checklist—helping you ensure the right areas are considered early.
- Risk assessment: Identify threats, vulnerabilities and impacts across the lifecycle.
- Data protection: Encryption, access control, secure storage and transfer.
- Security controls: Controls that protect CIA across environments and services.
- Access management: Roles, privileges, strong authentication, 2FA where required.
- Change management: Controlled change with traceability and approval.
- Security testing: Ongoing testing to identify weaknesses early.
- Incident response: Preparedness, escalation paths, learning and recovery.
ISO standards are often not freely available, but there are useful supporting resources (for example, iso27001security.com). There is also ISO/IEC 27034, which focuses more specifically on application security, though adoption is generally lower than ISO27001.
NIST 800–53
NIST is often valuable because it is publicly available, highly structured, and supports tailoring through control baselines. It also speaks more directly to lifecycle practices—especially when combined with secure development guidance such as NIST’s SSDF.
Under NIST 800–53B, baselines (low/moderate/high) help you select controls based on data sensitivity and threat level. Even in organisations with less mature governance, NIST can be adopted pragmatically as a control reference model and later mapped back into ISO27001-aligned assurance.
A simplified checklist view of lifecycle controls includes:
- Requirement analysis: Security objectives derived from context and need.
- Design review: Security architecture validated early.
- Development environment: Secure access, change control, automated testing.
- Testing and validation: Validate changes before production release.
- System integration: Secure integrations and dependency controls.
- Deployment: Harden, scan, patch and verify before go-live.
- Maintenance: Monitor, patch, and respond to new vulnerabilities.
CIS Security Controls
The CIS Controls provide a practical baseline for teams who want “a known good standard” that is measurable and widely recognised. That strength can also be a challenge: CIS is comprehensive, and teams often struggle to prioritise controls or demonstrate the business value of every safeguard when capacity is limited.
CIS Control 16 (Application Software Security) focuses on managing the security lifecycle of in-house developed, hosted, or acquired software—preventing weaknesses before they impact the enterprise. It includes safeguards such as:
- Maintaining a secure development process
- Managing third-party components
- Training developers in secure coding
- Separating production and non-production environments
- Conducting code-level checks and penetration testing
- Performing threat modelling and root-cause analysis
Used well, CIS provides a strong “due care” baseline and a consistent vocabulary for design, delivery and assurance functions.
Governance and Assurance Frameworks
Not all useful guidance comes in the form of a control catalogue. Some frameworks help you establish the processes, assurance patterns and organisational habits that allow technical controls to be applied consistently.
NCSC Application Security Guidance
The UK NCSC provides practical principles for secure development, including guidance on securing development environments, protecting code repositories, securing pipelines, and planning for flaws: NCSC Developers Collection
These principles are effective as design prompts. Teams still need to translate them into specific controls for their environment—for example, “protect your code repository” implies encryption, access control, auditing, secrets management, and supporting admin controls (vetting, training, JML processes).
OWASP
OWASP provides widely used guidance and standards for building and verifying application security, including the Application Security Verification Standard (ASVS), which defines three verification levels matched to risk and sensitivity. OWASP is particularly useful because it is accessible, practical, and commonly adopted by engineering teams.
COBIT, CMMI, and secure development frameworks
COBIT provides a governance view: how to align IT delivery to control and assurance outcomes. CMMI and related maturity approaches help organisations measure progress and embed consistent practice. NIST’s Secure Software Development Framework (SP 800-218) provides structured development guidance. ISO/IEC/IEEE 42010 supports architecture discipline and traceability in system design.
Together, these approaches help convert “security as intent” into “security as repeatable practice”.
“Due Care”
Directors and senior leaders have obligations to demonstrate due care in how sensitive data and critical services are managed. These expectations are reinforced through legislation and regulators (in the UK, the ICO plays a key role). When incidents occur, scrutiny often focuses on whether the organisation followed reasonable, defensible steps—whether it had appropriate governance, whether controls were implemented proportionately, and whether risk decisions were explicit.
Summary
These frameworks overlap for a reason: they converge on a shared understanding of what good looks like. The challenge is not a lack of guidance—it is choosing what is relevant, tailoring it to context, and embedding it into delivery so it is sustainable.
The “right” approach depends on your risk profile, your security posture and how your organisation governs technology. A useful pattern is to separate concerns by level:
- At the strategic level, agree principles, risk appetite and accountability.
- At programme level, define assurance needs, baselines and operating model expectations.
- At project level, turn those expectations into backlog items, acceptance criteria and repeatable pipelines.
- At release and operation level, keep controls alive through monitoring, review and improvement.
Threats evolve, tools change, and risk appetite shifts. Regular review against updated guidance—at milestones, releases and major change events—helps ensure your security posture remains aligned to need, not frozen in time.
Within that context, design leadership plays a critical role: selecting an approach that fits the organisation, translating it into practical controls teams can deliver, and ensuring assurance is credible without slowing progress unnecessarily.