ISO 27001:2022 Annex A 8.27: Building Secure Systems by Design
We often hear the phrase “secure by design,” but what does it actually mean in practice? Too often, security is bolted on at the end of a project like an afterthought—a firewall here, an encryption key there. But if the underlying architecture is flawed, no amount of patching can save it. This is where ISO 27001:2022 Annex A 8.27 comes in.
This control, titled Secure Systems Architecture and Engineering Principles, requires organisations to stop treating security as a final coat of paint and start treating it as the foundation. Whether you are building internal tools, customer-facing apps, or integrating third-party software, this control mandates that you establish, document, and apply security principles from day one.
Table of contents
What is Annex A 8.27?
In simple terms, Annex A 8.27 asks you to create a blueprint for security. It requires you to define a set of engineering principles that guide how you design, build, and maintain your systems. It’s a preventive control designed to ensure that information security is baked into every layer of your architecture—from the user interface down to the database and network infrastructure.
The goal is to reduce the number of vulnerabilities that make it into production. By following a standard set of rules, your developers and architects can avoid common pitfalls and build systems that are inherently resilient to attack.
Key Engineering Principles to Adopt
While the standard doesn’t give you a rigid list of principles, industry best practices (and common sense) point to several “must-haves” for any secure architecture. You should document these and ensure your teams understand them.
1. Least Privilege
This is the concept that a user (or a system process) should only have the bare minimum access rights necessary to perform their job. If a web server only needs to read from a database, it should never be given “write” or “delete” permissions. This limits the blast radius if that component is compromised.
2. Defence in Depth
Never rely on a single control. If your firewall fails, what’s next? If your password is stolen, is there MFA? Secure architecture assumes that one layer will eventually fail, so it lines up multiple layers of defence to keep the attacker out.
3. Zero Trust
The old model of “trust everything inside the network” is dead. Annex A 8.27 encourages a Zero Trust approach, where every request is verified, regardless of where it comes from. You should “never trust, always verify,” using strong authentication and encryption for internal traffic just as you would for external traffic.
4. Secure Defaults
Out of the box, your systems should be secure. Users shouldn’t have to dig through settings to turn on encryption or turn off insecure ports. Security should be the default state, not an option.
How to Implement This Control
Implementing Annex A 8.27 isn’t about buying a tool; it’s about changing your process. Here is a practical workflow to get you started:
Step 1: Document Your Principles
Create a “Secure Engineering Principles” document. This doesn’t have to be a novel. It can be a concise guide that outlines your stance on input validation, encryption standards, authentication methods, and secure interfaces. For more on how this fits into the wider framework, you can check ISO27001.com.
Step 2: Integrate into the Lifecycle
These principles need to live where the work happens. Integrate them into your project management and development lifecycles. For example, during the design phase of a new feature, require a “security architecture review” to check if the proposed design adheres to your documented principles.
Step 3: Separate Your Environments
A key part of secure architecture is segregation. You must separate your development, test, and production environments. This prevents a testing mishap from deleting live customer data and ensures that developers can’t accidentally (or maliciously) alter production code without going through the proper release channels.
Step 4: Extend to Third Parties
Don’t forget that this control applies to outsourced development too. If you hire an agency to build an app, your contract should explicitly state that they must follow your secure engineering principles. You are responsible for the security of the code they deliver.
What Auditors Look For
When the auditor comes knocking, they aren’t going to read your code line-by-line. They are going to look for evidence that your principles exist and are being used. You should be ready to show:
- Your documented Secure Systems Engineering Principles.
- Design documents or architectural diagrams that reference these principles.
- Records of security reviews conducted during the design phase of recent projects.
- Contracts with third-party developers that include security requirements.
Conclusion
ISO 27001 Annex A 8.27 is about moving from “security as a hurdle” to “security as an enabler.” By defining clear architectural principles, you give your teams the guidance they need to build fast and safe. It minimizes technical debt, reduces the risk of data breaches, and ultimately builds a stronger, more trustworthy product.
