How to Design Systems That Are Secure by Default – Not by Luck
ISO 27001 Control 8.27 Secure system architecture and engineering principles is about how you design and build systems, not just how you configure them afterwards.
The control expects you to have clear, documented security principles that guide:
- how you design systems and integrations
- how you choose technologies and patterns
- how you harden and deploy platforms
- how you evolve architecture as threats and business needs change
In other words, you don’t just “do security” at the edges – you design it into the architecture, components and data flows from the start.
This guide explains what ISO 27001 Control 8.27 is really asking for and how to apply secure architecture and engineering principles in a practical, reusable way.
What ISO 27001 Control 8.27 Actually Requires
In plain English, ISO 27001 Control 8.27 – Secure system architecture and engineering principles expects you to:
- Define security design principles that apply to systems, applications, cloud services and infrastructure.
- Use those principles consistently in solution design, engineering and change – not just in theory.
- Consider risk, business requirements, data sensitivity and threat landscape when designing systems.
- Apply defence in depth, least privilege, secure-by-design and zero trust concepts sensibly.
- Review and evolve architecture as technology and threats change.
An auditor will typically look for evidence that:
- You have security architecture / engineering principles documented.
- Projects and changes actually use them – in design docs, patterns, standards and reviews.
- The same ideas show up in cloud builds, networks, applications and integrations, not just in one area.
Step 1 – Define (and Write Down) Your Security Design Principles
Start by agreeing the high-level principles you want architects and engineers to follow.
For example:
- Security by design – security built into requirements, design and implementation from day one.
- Defence in depth – multiple layers of control so one failure doesn’t mean full compromise.
- Least privilege – users, services and components only get the access they actually need.
- Zero trust mindset – don’t automatically trust anything based on being “inside the network”.
- Secure-by-default configurations – services are locked down unless deliberately opened up.
- Fail safe, not fail open – when something goes wrong, it should fail in a secure way.
- Standardisation over improvisation – reusable patterns and reference architectures where possible.
Capture these in a short, practical “Secure Architecture & Engineering Principles” document – something people will actually read, not a 70-page treatise.
Step 2 – Translate Principles into Practical Architecture Patterns
Principles are useful, but people need something they can copy and adapt.
Create simple, reusable patterns such as:
- Typical internet-facing service pattern
– Web tier in a DMZ / public subnet
– Separate app tier and data tier in private networks
– WAF in front, strict firewall rules, central logging, TLS everywhere - Typical internal business app pattern
– Front end behind SSO and MFA
– Segregated internal network segments
– Role-based access and audited admin interfaces - Cloud reference architecture
– Use of landing zones, network segmentation, secure baselines, managed identities, key management, logging and monitoring. - Integration pattern
– API gateway, authentication between services, rate limiting, message signing or mTLS where needed, clear error handling.
These patterns show how your secure system architecture and engineering principles play out in practice – and they massively speed up secure design for new projects.
Step 3 – Apply Defence in Depth Sensibly
Defence in depth doesn’t mean “throw every control at every problem”; it means layers that make sense together.
For ISO 27001 Control 8.27, think about:
- Network layer
– Segmentation between internet, DMZ, internal, sensitive and management networks.
– Firewalls, security groups, NSGs, or equivalent at key boundaries. - Host / platform layer
– Hardened OS images, secure configuration baselines, patching and configuration management.
– Minimal services enabled; admin access restricted and logged. - Application layer
– Authentication, authorisation, input validation, output encoding.
– Protection against common vulnerabilities (e.g. OWASP Top 10). - Data layer
– Encryption at rest, tightly controlled access paths, audit trails.
– Backup and recovery, including integrity checks. - Monitoring and response
– Central logging, correlation in a SIEM, alerting on suspicious activity.
– Defined incident response process.
The important thing: if one control fails (for example, a web server vulnerability), the attacker should still have to fight through several more layers to get to anything important.
Step 4 – Build Least Privilege and Access Control into the Architecture
Least privilege shouldn’t be an afterthought – it should be baked into your design choices.
Architectural expectations should include:
- Identity as a first-class component
– Use central identity providers (IdPs) where possible.
– Prefer role-based or attribute-based access models. - Service-to-service access
– Use managed identities, service principals or certificates, not shared local accounts.
– Limit each service’s access to only the data and operations it needs. - Admin and break-glass access
– Dedicated admin accounts with MFA.
– Clear separation of duties and strong logging around privileged actions. - Review and recertification
– Regular review of high-privilege roles and access to sensitive environments.
This is exactly the kind of thinking ISO 27001 Control 8.27 expects to see in system architecture, not just policies.
Step 5 – Design for Secure Data Handling and Cryptography
Link your architecture to your cryptographic and data protection standards (Control 8.24).
From an architecture and engineering perspective, define:
- Where data is stored
– Which data stores handle which classifications.
– How backups and archives are protected. - How data flows
– Data flow diagrams showing where sensitive data moves between components.
– Points where encryption, masking or tokenisation are required. - Key management
– Which key management systems are used (cloud KMS, HSMs, vaults).
– How keys are separated between environments and systems. - DLP and exfiltration controls
– Where you’ll enforce restrictions on copying, exporting or exfiltrating data (e.g. proxies, CASB, endpoint controls).
This ensures your architecture is explicitly designed to protect sensitive information, not just relying on individual developer decisions.
Step 6 – Incorporate Zero Trust Thinking Where It Makes Sense
You don’t have to adopt a full-blown zero trust programme to apply the underlying ideas.
Architecturally, this usually means:
- Don’t rely on “inside the network = trusted”
– Internal services still need authentication and authorisation.
– Access to management interfaces is tightly controlled, not just “on the VPN”. - Verify explicitly
– Devices, users and services must authenticate and be authorised every time – not just once at the perimeter. - Apply context to decisions
– Use device posture, location, risk level and data sensitivity to influence access decisions. - Encrypt by default
– Treat internal traffic as potentially hostile; use TLS for service-to-service calls.
You can show auditors that ISO 27001 Control 8.27 is met by explaining how your architecture reflects these ideas in a measured, risk-based way.
Step 7 – Engineer for Hardening, Configuration Management and Change
Secure architecture isn’t just drawings; it’s how systems are actually built and changed.
Engineering expectations should include:
- Standard hardened builds
– Baseline images for servers, containers, devices and cloud resources.
– Baseline templates for networks, load balancers, storage, etc. - Infrastructure as code where possible
– Repeatable, reviewable and version-controlled infrastructure builds.
– Code review and automated checking for infrastructure changes. - Configuration management
– Tools and processes to enforce baselines and flag drift.
– Routine patching and maintenance built into operations. - Secure integration
– Clear guidelines for connecting systems (API patterns, message bus usage, secure endpoints).
– Validation that security controls still work once systems are integrated.
ISO 27001 Control 8.27 is as interested in how you manage the estate over time as how you first designed it.
Step 8 – Tie Architecture to Monitoring, Logging and Incident Response
A secure architecture must also be observable.
Specify in your architecture principles that:
- All critical components must log security-relevant events
– Auth events, access control decisions, configuration changes and key system actions.
– Logs must be forwarded to central logging or SIEM platforms. - Monitoring is a design requirement
– Health, performance and security monitoring are part of the solution design, not added at the end. - Incident response hooks exist
– The architecture supports isolation, containment and recovery (for example, the ability to isolate a subnet, disable a service, rotate keys).
This ties Control 8.27 directly into your security operations and incident management arrangements.
Step 9 – Include Third Parties, Cloud and Outsourced Development
Modern architectures are rarely self-contained. ISO 27001 Control 8.27 expects your principles to cover third-party and cloud scenarios too.
That means:
- Cloud platforms
– Cloud architectures follow the same principles (segmentation, least privilege, encryption, logging) using native controls.
– You have reference patterns for common cloud setups. - Third-party systems and integrations
– Security expectations are reflected in interface and integration designs (e.g. mTLS, API gateway, rate limiting, strong authentication).
– Data sharing, processing and residency requirements are designed in, not bolted on. - Outsourced development or managed services
– Contracts require suppliers to adhere to your secure architecture and engineering principles.
– You review supplier designs and implementations where they affect your risk.
The key point: your architecture is end-to-end, not just for the bits you host on your own kit.
Step 10 – Keep Architecture and Principles Alive
Finally, Control 8.27 wants this to be ongoing, not a one-off exercise.
Build in:
- Regular reviews
– Architecture and principles reviewed periodically or after major incidents / changes.
– Retire outdated patterns; introduce new ones as technologies and threats evolve. - Architecture governance
– Design reviews for significant projects or changes, checking against your security principles and patterns.
– Clear criteria for exceptions and the process to approve and record them. - Awareness and training
– Architects, engineers and DevOps teams get familiar with the principles and patterns.
– Security architects or “security champions” support teams during design and build.
This shows that secure system architecture and engineering is a living practice, not just a static policy document.
Quick Implementation Checklist for ISO 27001 Control 8.27
Use this to gauge where you are with secure system architecture and engineering principles:
- ISO 27001 Control 8.27 (Secure system architecture & engineering principles) is covered in a documented set of principles and patterns.
- Those principles are used in real designs, not just written down (evidence in diagrams, design docs, patterns, cloud templates).
- You have reference architectures / patterns for common use cases (internet-facing apps, internal apps, cloud landing zones, integrations).
- Defence in depth, least privilege and secure-by-default are clearly visible in network, host, application and data layers.
- Architectures apply strong identity and access control, including service identities and admin access.
- Data handling and cryptography are explicitly designed into architectures, aligned with classification and cryptography standards.
- Zero trust ideas (verify explicitly, don’t trust by location, encrypt by default) are reflected in design decisions where appropriate.
- Systems are hardened, managed as code where possible, and subject to configuration management and patching.
- Architectures include logging, monitoring and incident response hooks by design.
- Third-party, cloud and outsourced components are covered by the same security architecture expectations, backed by contracts and reviews.
- Principles and patterns are reviewed and updated as threats, technology and business needs evolve.
Bringing It All Together
ISO 27001 Control 8.27 – Secure system architecture and engineering principles – is about moving from “we secure things afterwards” to:
“We build and change systems in line with a clear, consistent set of security principles.”
If you:
- Define those principles clearly,
- Turn them into usable reference architectures and patterns,
- Make sure projects and suppliers actually follow them, and
- Keep them alive as your environment changes,
you’ll have a strong story for auditors – and, more importantly, a technology estate that’s secure by design instead of secure by hope.
Explore the ISO 27001 Control Group Purposes