Overview
To ensure systems are securely designed, implemented, and operated across their lifecycle, we must apply modern, adaptable engineering principles rooted in transparency, modularity, and resilience. These principles are not fixed rules—they are living standards shaped by experience, emerging threats, and user context.
The Department of Education draws upon both industry guidance and internal policy to continuously refine its architecture and engineering approach.
Core engineering principles for secure systems
| Principle | Best practice controls |
|---|---|
| Separation of concerns | Architect systems so that logic, data, and presentation layers are clearly separated. This promotes security isolation and easier updates. Applied in our developer portal using modular architecture and microservices. |
| Least privilege & zero trust | Systems and services should only have the minimum access required. Use role-based access controls (RBAC) and environmental separation. Avoid “trusted” zones—assume compromise and validate every action. |
| Modular, composable design | Build systems from small, well-defined, independently testable components. This enables scoped security controls, faster incident response, and safe re-use. |
| Secure defaults & hardening | Every system should use secure defaults—e.g., encrypted connections, disabled open ports, logging enabled by default. Infrastructure as Code (IaC) should enforce these (e.g., Bicep, Terraform with security baselines). |
| Defence in depth | Security controls must not rely on a single layer. Combine network rules, application firewalls, validation checks, and secure user journeys to guard against multi-vector threats. |
| Change responsiveness | Architectures must anticipate change. Use API-first design, contract testing, and event-driven services to support continuous integration while maintaining security boundaries. |
| Proven patterns, not rigid templates | Encourage use of proven design patterns, but allow deviation when context demands it. Every architecture should be critically assessed—not copied unthinkingly. |
| Observability and traceability | Build in monitoring from day one. Use application logs, distributed tracing, and structured audit events to support incident response and continuous improvement. |
| Documentation through living artefacts | Use lightweight, version-controlled architectural artefacts (e.g., Markdown READMEs, diagrams as code) that evolve alongside the system, not static DOCs or PDFs that become outdated. |
| Human-centred design | Security must not come at the cost of usability. Systems should be co-designed with users and stakeholders to ensure secure behaviour is natural, not burdensome. |
Supporting tools & frameworks
| Tool / Technique | Purpose |
|---|---|
| Azure DevOps pipelines | Secure, auditable CI/CD pipelines with defined approval gates and secret injection |
| GitHub with feature branching | Clear, auditable change history; supports modular secure development |
| SonarQube / ESLint | Code quality and vulnerability scanning for every commit |
| Dependabot / Snyk | Automated dependency scanning and patch suggestions |
| Terraform / Bicep | Infrastructure as Code for secure, repeatable deployments |
| OWASP cheat sheets & ASVS | Reference security checklists for architectural decisions |
| Architecture Decision Records (ADRs) | Version-controlled architectural reasoning that evolves with the solution |
Continuous alignment and refinement
- Architecture should not be a one-time exercise. Systems must evolve in alignment with emerging risks, technologies, and use-cases.
- Teams should review architectural decisions regularly as part of retrospectives or feature reviews.
- Security architects and engineering leads are encouraged to share lessons learned and reusable patterns across teams.
- Ongoing support should be made available via Communities of Practice (COP) and review forums.