Security Architecture: [System name]
Complete security architecture document for one system: scope and
assets, trust boundaries, threat model, security requirements, identity
and access, data protection, network, application security, detection,
incident response, secrets, third parties, compliance mapping and
residual risk. Based on the systems security engineering principles of
NIST SP 800-160 Volume 1 (public domain) and the STRIDE threat
categories. Replace every [bracketed] value and every row marked
Example. Worked examples use a customer-facing web application with a
payment integration.
Document control
| Field | Value |
|---|
| Document ID | [SEC-ARCH-SHOP-001] |
| System | [Online shop platform] |
| Release described | [v3.2 / target architecture YYYY] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Security architect | [@security-architect] |
| System owner | [@system-owner] |
| Classification | Confidential |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least annually and on major change) |
| Related | [Architecture description], [Threat model workshop notes], [Risk register] |
Approvals
| Role | Name | Decision | Date |
|---|
| System owner (risk owner) | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Security architect | [@name] | [Decision] | YYYY-MM-DD |
| Chief information security officer or delegate | [@name] | [Decision] | YYYY-MM-DD |
| Privacy / data protection officer | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after threat modelling workshop |
| 0.2 | YYYY-MM-DD | [@name] | Example: Added payment provider trust boundary; threats T-07 to T-09 |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; residual risks RR-01 and RR-02 accepted |
Contents
1. Introduction
1.1 Purpose
[What this document decides and records. Example: "This document describes
how the online shop protects customer accounts, orders and payment
flows, and records the security risks accepted by the system owner for
release 3.2."]
1.2 Audience
Engineering leads, platform and operations teams, security reviewers,
auditors and the system owner who accepts residual risk.
1.3 Security design principles
The design applies the following principles, derived from the systems
security engineering principles in NIST SP 800-160 Volume 1. Each row
states how the principle shows up in this system.
| ID | Principle | How it is applied here |
|---|
| P-01 | Least privilege | Example: Each service has its own identity and only the permissions listed in 6.3 |
| P-02 | Defence in depth | Example: WAF, authentication at the gateway, authorisation in each service, encryption of data stores |
| P-03 | Secure defaults | New endpoints require authentication unless explicitly marked public in code review |
| P-04 | Minimise attack surface | Only the gateway is reachable from the internet; admin tools are private |
| P-05 | Separation of duties | Production deploys require a second approver; no engineer holds standing admin rights |
| P-06 | Fail securely | Authorisation errors deny; dependency failures never bypass checks |
| P-07 | Trust nothing implicitly | Every service call is authenticated with workload identity, inside the network too |
| P-08 | Traceability | Security-relevant actions are logged with actor, time and request ID |
| [P-nn] | [Principle] | [Application] |
2. Scope, assets and security objectives
2.1 Scope
| In scope | Out of scope |
|---|
| Example: Storefront web app, mobile API, order and customer services, admin console | Corporate laptops and email (covered by enterprise security) |
Example: Cloud account [shop-prod], CI/CD pipelines | Payment card processing inside the payment provider's hosted page |
| [Item] | [Item] |
2.2 Asset register
| ID | Asset | Type | Classification | Confidentiality | Integrity | Availability | Owner |
|---|
| A-01 | Customer accounts and credentials | Data | Personal | High | High | Medium | [@owner] |
| A-02 | Order and address history | Data | Personal | High | High | Medium | [@owner] |
| A-03 | Payment tokens from provider | Data | Sensitive | High | High | High | [@owner] |
| A-04 | Product prices and promotions | Data | Internal | Low | High | High | [@owner] |
| A-05 | Checkout service | Service | n/a | Medium | High | High | [@owner] |
| A-06 | Signing keys and API secrets | Credential | Secret | Critical | Critical | High | [@owner] |
| A-07 | CI/CD pipeline and build artefacts | Process | Internal | Medium | Critical | Medium | [@owner] |
| [A-nn] | [Asset] | [Type] | [Class] | [L / M / H] | [L / M / H] | [L / M / H] | [@owner] |
2.3 Security objectives
| ID | Objective | Measure |
|---|
| SO-01 | No unauthorised access to another customer's data | Zero confirmed incidents; authorisation tests in CI |
| SO-02 | Prices and orders cannot be tampered with by clients | Server-side price calculation; integrity tests |
| SO-03 | Detect account takeover attempts quickly | Credential-stuffing detection within [5 minutes] |
| SO-04 | Restore service after a security incident | RTO [4 hours], RPO [15 minutes] |
| [SO-nn] | [Objective] | [Measure] |
3. Architecture and trust boundaries
The diagram shows the main components and the four trust boundaries
(TB). Data flows crossing a boundary are numbered and analysed in
section 4.
| Boundary | Separates | Controls at the boundary |
|---|
| TB1 to TB2 | Internet and edge | TLS 1.2+, WAF managed rules, bot management, rate limits |
| TB2 to TB3 | Edge and services | Token validation at gateway, mTLS to services, schema validation |
| TB3 to TB4 | Services and data | Per-service database credentials, private endpoints, encryption |
| TB3 to third parties | Services and payment provider / identity provider | Outbound allow-list, signed webhooks, mutual secrets rotated |
4. Threat model
4.1 Method
Threats were identified with STRIDE per element in a workshop on
YYYY-MM-DD with [participants]. Risk is scored as:
R=L×I,L,I∈{1,2,3,4,5} with High at R≥15, Medium at 8≤R<15 and Low below 8.
4.2 STRIDE categories
| Category | Property violated | Typical question |
|---|
| Spoofing | Authenticity | Can someone pretend to be another user or service? |
| Tampering | Integrity | Can data or code be changed without authorisation? |
| Repudiation | Non-repudiation | Can someone deny an action because it was not recorded? |
| Information disclosure | Confidentiality | Can data reach someone not entitled to it? |
| Denial of service | Availability | Can the service be made unavailable or too slow? |
| Elevation of privilege | Authorisation | Can someone gain rights they should not have? |
4.3 Threat register
| ID | Element / flow | STRIDE | Threat | L | I | R | Controls | Status |
|---|
| T-01 | F1, storefront login | S | Credential stuffing with leaked passwords | 5 | 4 | 20 | SR-03, C-IAM-02, C-DET-01 | Mitigated |
| T-02 | F3, order API | T | Client changes item price in checkout request | 4 | 4 | 16 | SR-06 (server-side pricing) | Mitigated |
| T-03 | Order service | E | Broken object-level authorisation exposes other customers' orders | 4 | 5 | 20 | SR-04, C-APP-03 | Mitigated |
| T-04 | Admin console | R | Support agent changes an address without trace | 3 | 3 | 9 | SR-09, C-DET-02 | Mitigated |
| T-05 | F4, database | I | Backup copy exposed through misconfigured storage | 2 | 5 | 10 | C-DATA-03, C-POL-01 | Mitigated |
| T-06 | Edge | D | Volumetric attack on checkout during sale | 3 | 4 | 12 | C-NET-01, autoscaling | Partially mitigated |
| T-07 | F6, payment webhook | S | Forged payment confirmation marks order paid | 3 | 5 | 15 | SR-07 (signature check) | Mitigated |
| T-08 | CI/CD | T | Compromised dependency injects code into build | 3 | 5 | 15 | C-APP-05, C-SC-01 | Partially mitigated |
| T-09 | Secrets manager | I | Over-broad secret read permission | 2 | 5 | 10 | C-SEC-02 | Mitigated |
| [T-nn] | [Element] | [S/T/R/I/D/E] | [Threat] | [1-5] | [1-5] | [L x I] | [IDs] | [Status] |
5. Security requirements
| ID | Requirement | Source | Priority | Verification |
|---|
| SR-01 | All external traffic uses TLS 1.2 or later with HSTS (max-age at least 1 year) | P-02 | Must | Automated TLS scan |
| SR-02 | Customer passwords are stored with a memory-hard hash (Argon2id or equivalent) | A-01 | Must | Code review |
| SR-03 | Login is protected by rate limiting, breached-password checks and optional MFA | T-01 | Must | Integration test, pen test |
| SR-04 | Every request for a customer-owned object checks ownership in the service | T-03 | Must | Authorisation test suite |
| SR-05 | Admin users authenticate with phishing-resistant MFA | P-01 | Must | IdP policy review |
| SR-06 | Prices, discounts and totals are computed on the server only | T-02 | Must | Unit and abuse tests |
| SR-07 | Payment provider webhooks are verified by signature and timestamp | T-07 | Must | Integration test |
| SR-08 | Personal data in non-production environments is masked | A-01, A-02 | Must | Data scan |
| SR-09 | Security-relevant events are logged and retained for [1 year] | T-04 | Must | Log review |
| [SR-nn] | [Requirement] | [Threat / asset / principle] | [Must / Should] | [Method] |
6. Identity and access management
6.1 Identities
| Identity type | Authenticated by | Authorisation model | Lifecycle |
|---|
| Customer | Example: Identity provider, OIDC, password plus optional passkey | Ownership checks per object | Self-service; deleted on request |
| Staff (support, admin) | Corporate SSO with phishing-resistant MFA | Role-based, roles in 6.2 | Joiner-mover-leaver from HR system |
| Service workloads | Workload identity, short-lived certificates | Per-service policy (6.3) | Created by IaC, rotated automatically |
| CI/CD pipeline | OIDC federation to cloud, no long-lived keys | Deploy role per environment | Managed in IaC |
| [Type] | [Method] | [Model] | [Lifecycle] |
6.2 Staff roles
| Role | Can | Cannot | Approval |
|---|
| Support agent | View orders, change delivery address, issue refunds up to [100 EUR] | Export customer lists, change prices | Team lead |
| Support supervisor | Above plus refunds up to [1 000 EUR] | Change roles | Head of support |
| Platform admin (just-in-time) | Infrastructure changes during an approved window | Read customer data without a ticket | Change approver, time-limited |
| [Role] | [Can] | [Cannot] | [Approver] |
6.3 Privileged access
- No standing administrator access in production; access is requested,
approved and granted for at most [4 hours].
- Privileged sessions are recorded. Break-glass accounts are sealed,
alerted on use and reviewed within one business day.
- Access reviews: [quarterly] for staff roles, [monthly] for privileged roles.
6.4 Identity controls
| ID | Control |
|---|
| C-IAM-01 | Single identity provider for customers and staff; no local accounts in services |
| C-IAM-02 | Login protection: per-account and per-IP throttling, breached-password check, step-up MFA on risk signals |
| C-IAM-03 | Sessions expire after [30 minutes] idle for staff and [30 days] for customers; revocable centrally |
| C-IAM-04 | Workload identities issued by the platform; no static service passwords |
| [C-IAM-nn] | [Control] |
7. Data protection
7.1 Data classification and handling
| Classification | Examples in this system | Storage rule | Transfer rule |
|---|
| Sensitive | Payment tokens, identity documents | Dedicated store, field-level encryption | Never in logs or analytics |
| Personal | Name, email, address, order history | Encrypted store, access logged | Only to processors under contract |
| Internal | Prices, stock levels | Encrypted at rest | Internal networks |
| Public | Product descriptions | No restriction | No restriction |
7.2 Encryption
| Layer | Control | Detail |
|---|
| In transit, external | TLS 1.2+ with modern cipher suites | Certificates from [managed CA]; auto-renewed |
| In transit, internal | mTLS between services | Service mesh issues 24-hour certificates |
| At rest, databases | Storage encryption with customer-managed keys | Key per environment |
| At rest, object storage | Server-side encryption, bucket policies deny unencrypted uploads | |
| Field level | Envelope encryption for [phone number, date of birth] | Data key per record, wrapped by KMS key |
| Backups (C-DATA-03) | Encrypted, stored in a separate account, public access blocked by policy C-POL-01 | Policy-as-code check fails any public bucket |
7.3 Key management
| Key | Purpose | Store | Rotation | Access |
|---|
db-prod-cmk | Database encryption | Cloud KMS (HSM-backed) | Yearly, automatic | Database service only |
pii-field-key | Field-level encryption | Cloud KMS | Yearly; data re-wrapped | Customer service role |
jwt-signing | Token signing | Identity provider | 90 days, overlap 7 days | IdP only |
| [Key] | [Purpose] | [Store] | [Rotation] | [Access] |
7.4 Minimisation and retention
[State what personal data is not collected, how long each category is kept
and how deletion requests are fulfilled across stores and backups.]
8. Network security and segmentation
| Zone | Contains | Inbound allowed from | Outbound allowed to |
|---|
| Edge | CDN, WAF, gateway | Internet on 443 | Application zone on 443 |
| Application | Services | Edge, same zone (mTLS) | Data zone, egress proxy |
| Data | Databases, caches, queues | Application zone on service ports | None |
| Management | Bastion-less access via session manager, CI runners | Corporate SSO only | All zones on management ports, logged |
| Egress proxy | Outbound gateway | Application zone | Allow-listed domains: payment provider, IdP, email provider |
| ID | Control |
|---|
| C-NET-01 | DDoS protection and WAF managed rule sets with [OWASP core rules] at the edge |
| C-NET-02 | Security groups / network policies deny by default; rules defined in IaC and reviewed |
| C-NET-03 | Private endpoints for managed data services; no public IPs on data stores |
| C-NET-04 | Egress restricted to an allow-list through the proxy; DNS logging enabled |
| [C-NET-nn] | [Control] |
9. Application security
| ID | Control | Stage | Evidence |
|---|
| C-APP-01 | Threat modelling for every new feature crossing a trust boundary | Design | Updated section 4 |
| C-APP-02 | Static analysis on every pull request; high findings block merge | Build | CI report |
| C-APP-03 | Central authorisation library with object-ownership checks; tests for each endpoint | Code | Test suite |
| C-APP-04 | Input validation against schemas at the gateway and services; output encoding in templates | Code | Code review checklist |
| C-APP-05 | Dependency scanning and lockfiles; new packages reviewed; known-exploited vulnerabilities patched within [7 days] | Build | SCA report |
| C-APP-06 | Security headers: CSP, HSTS, X-Content-Type-Options, frame-ancestors | Deploy | Header scan |
| C-APP-07 | Dynamic scanning in staging; annual external penetration test | Test | Reports |
| C-APP-08 | Signed build artefacts and provenance; only signed images deploy | Release | Admission policy |
| [C-APP-nn] | [Control] | [Stage] | [Evidence] |
10. Secrets management
| Topic | Rule |
|---|
| Store | Example: Central secrets manager; one path per service and environment |
| Access | C-SEC-02: each workload identity reads only its own path; humans read production secrets only via break-glass |
| Delivery | Injected at runtime as files or via SDK; never baked into images |
| Rotation | Database credentials dynamic (1 hour); third-party API keys every [90 days]; immediate on suspected leak |
| Detection | C-SEC-03: secret scanning on every push and on the full history weekly |
| Inventory | Secrets register with owner and rotation date, reviewed quarterly |
11. Logging, monitoring and detection
| Source | Events | Destination | Retention |
|---|
| Gateway | Requests, auth failures, rate-limit hits | SIEM | [1 year] |
| Identity provider | Logins, MFA events, password resets | SIEM | [1 year] |
| Services | Authorisation denials, admin actions, refunds | SIEM | [1 year] |
| Cloud control plane | IAM changes, key usage, network changes | SIEM, immutable archive | [2 years] |
| [Source] | [Events] | [Destination] | [Retention] |
| ID | Detection | Threshold | Response |
|---|
| C-DET-01 | Credential stuffing | More than [50] failed logins per IP or [500] per minute globally | Auto-block and page on call |
| C-DET-02 | Unusual admin activity | Refunds by one agent above [3x] their 30-day average | Ticket to support supervisor |
| C-DET-03 | Privilege escalation in cloud | Any IAM policy change outside IaC pipeline | Page security on call |
| C-DET-04 | Data exfiltration | Egress to non-allow-listed domain | Block and alert |
| [C-DET-nn] | [Detection] | [Threshold] | [Response] |
12. Incident response integration
| Item | Value |
|---|
| Incident process | [Link to the organisation's incident response plan] |
| Security on-call | [@security-oncall], paged through [tool] |
| System contacts | [@system-owner], [@tech-lead], [@platform-oncall] |
| Playbooks | Account takeover, data exposure, compromised secret, ransomware, payment fraud |
| Containment levers | Disable logins per tenant, revoke all sessions, rotate secrets, block IP ranges at WAF, put checkout in maintenance mode |
| Evidence sources | SIEM, cloud audit trail, database audit log, snapshot of affected hosts |
| Notification duties | [Data protection authority and customers per applicable law; confirm with legal] |
| Last exercise | YYYY-MM-DD, scenario [name], findings [link] |
13. Third-party and supply chain risk
| ID | Supplier / component | Function | Data shared | Assurance | Contract controls | Review |
|---|
| C-SC-01 | Open-source dependencies | Libraries | None | SCA, SBOM, provenance checks | n/a | Continuous |
| TP-01 | Example: Payment provider | Card processing | Order ID, amount; card data entered on provider page | [PCI DSS attestation] | DPA, breach notice within [24 h] | Annual |
| TP-02 | Example: Email delivery provider | Transactional email | Email address, order summary | [Independent audit report] | DPA | Annual |
| TP-03 | Example: Identity provider | Customer and staff login | Credentials, profile | [Audit report] | DPA, uptime SLA | Annual |
| [TP-nn] | [Supplier] | [Function] | [Data] | [Evidence] | [Controls] | [Frequency] |
14. Compliance mapping
| Obligation or framework | Requirement area | Controls in this document | Evidence | Status |
|---|
| Example: Data protection law (for example GDPR) | Security of processing, data minimisation | 7.1 to 7.4, SR-08 | DPIA [link] | Compliant |
| Example: Payment card industry standard | Scope reduction through hosted payment page | 2.1, TP-01 | Self-assessment | Compliant |
| Example: Information security management system (ISO/IEC 27001) | Access control, cryptography, logging | 6, 7.2, 11 | Statement of applicability | Partially |
| [Framework] | [Area] | [Controls] | [Evidence] | [Status] |
15. Traceability, residual risks and acceptance
15.1 Traceability
| Threat | Requirement(s) | Control(s) | Verification | Result |
|---|
| T-01 | SR-03 | C-IAM-02, C-DET-01 | Pen test YYYY-MM-DD | Pass |
| T-03 | SR-04 | C-APP-03 | Authorisation test suite | Pass |
| T-07 | SR-07 | Webhook signature check | Integration test | Pass |
| T-08 | n/a | C-APP-05, C-APP-08, C-SC-01 | SBOM and provenance check | Partial |
| [T-nn] | [SR] | [C] | [Method] | [Result] |
15.2 Residual risks
| ID | Risk | Related threats | Residual rating | Reason not fully mitigated | Planned treatment | Owner | Accepted until |
|---|
| RR-01 | Example: Application-layer DDoS during peak sales could degrade checkout | T-06 | Medium | Cost of always-on scrubbing above budget | Queue-based checkout by Q3 | [@owner] | YYYY-MM-DD |
| RR-02 | Example: Transitive dependency compromise before detection | T-08 | Medium | Provenance not available for all packages | Pin and verify top 50 packages | [@owner] | YYYY-MM-DD |
| [RR-nn] | [Risk] | [T] | [L / M / H] | [Reason] | [Treatment] | [@owner] | YYYY-MM-DD |
15.3 Exceptions to security baseline
| ID | Baseline requirement | Deviation | Compensating control | Approved by | Expires |
|---|
| EX-01 | Example: All admin tools behind SSO | Legacy reporting tool uses local accounts | IP allow-list, MFA plug-in, monthly review | [@name] | YYYY-MM-DD |
| [EX-nn] | [Requirement] | [Deviation] | [Control] | [@name] | YYYY-MM-DD |
16. Appendices
16.1 Glossary
| Term | Meaning |
|---|
| Trust boundary | A line where the level of trust changes, such as between the internet and the gateway |
| STRIDE | Threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege |
| mTLS | Mutual TLS: both client and server present certificates |
| Residual risk | Risk remaining after controls are applied |
| SIEM | Security information and event management platform |
| [Term] | [Meaning] |
16.2 References
| Reference | Use |
|---|
| NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems | Design principles in 1.3 |
| STRIDE threat categories (Microsoft) | Threat classification in section 4 |
| [OWASP Application Security Verification Standard] | Detailed application requirements |
| [Organisation security policy and baseline] | Baseline for exceptions in 15.3 |
Standard and licence note
Based on NIST SP 800-160 Volume 1, Engineering Trustworthy Secure
Systems (public domain, U.S. Government work), for the systems security
engineering principles, and on the STRIDE threat categories for threat
modelling. This template is original text written for this collection; it
is a format for recording design decisions, not legal or compliance
advice. Template licence: MIT.