# 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.

<!--
Guidance: How to use this template
- Work in this order: assets (2), trust boundaries (3), threats (4), then
  requirements (5) and controls (6 to 13). Controls that do not trace to a
  threat or a requirement are either missing a justification or not needed.
- Give every threat, requirement and control an ID so section 15 can trace
  them. Reviewers will check that every high threat has a control and a test.
- Describe what is actually built, not the policy. Where the system departs
  from the corporate baseline, say so and record the exception in section 15.
- This document is a design record, not legal or compliance advice. Have the
  compliance mapping in section 14 confirmed by the responsible function.
-->

## Document control

<!-- Guidance: Identify the system, the release and the people accountable for accepting its security risk. -->

| 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

<!-- Guidance: Record changes to the threat model, controls and accepted risks. -->

| 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

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction](#1-introduction)
2. [Scope, assets and security objectives](#2-scope-assets-and-security-objectives)
3. [Architecture and trust boundaries](#3-architecture-and-trust-boundaries)
4. [Threat model](#4-threat-model)
5. [Security requirements](#5-security-requirements)
6. [Identity and access management](#6-identity-and-access-management)
7. [Data protection](#7-data-protection)
8. [Network security and segmentation](#8-network-security-and-segmentation)
9. [Application security](#9-application-security)
10. [Secrets management](#10-secrets-management)
11. [Logging, monitoring and detection](#11-logging-monitoring-and-detection)
12. [Incident response integration](#12-incident-response-integration)
13. [Third-party and supply chain risk](#13-third-party-and-supply-chain-risk)
14. [Compliance mapping](#14-compliance-mapping)
15. [Traceability, residual risks and acceptance](#15-traceability-residual-risks-and-acceptance)
16. [Appendices](#16-appendices)

## 1. Introduction

<!-- Guidance: Why this document exists, who should read it and the design principles that shape every decision below. -->

### 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

<!-- Guidance: What is protected, how valuable it is and what "secure" means for this system. Assets drive everything else. -->

### 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

<!-- Guidance: Show components, data flows and where trust changes. Every arrow that crosses a boundary is a place to authenticate, authorise, validate and log. -->

The diagram shows the main components and the four trust boundaries
(TB). Data flows crossing a boundary are numbered and analysed in
section 4.

```mermaid
flowchart LR
  subgraph TB1["TB1: Internet (untrusted)"]
    user([Customer browser / app])
    attacker([Anonymous client])
  end
  subgraph TB2["TB2: Edge"]
    cdn[CDN and WAF]
    gw[API gateway]
  end
  subgraph TB3["TB3: Application network"]
    web[Storefront service]
    order[Order service]
    cust[Customer service]
    admin[Admin console]
  end
  subgraph TB4["TB4: Data tier"]
    db[(Customer and order DB)]
    vault[(Secrets manager)]
  end
  psp["Payment provider (third party)"]
  idp["Identity provider"]
  user -->|"F1 HTTPS"| cdn --> gw
  attacker -.-> cdn
  gw -->|"F2 mTLS"| web
  gw -->|"F3 mTLS"| order
  order -->|"F4 TLS"| db
  cust -->|"F5 TLS"| db
  order -->|"F6 HTTPS"| psp
  gw -->|"F7 OIDC"| idp
  admin -->|"F8 private link"| cust
  order --> vault
```

| 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

<!-- Guidance: Apply STRIDE to each element and each boundary-crossing flow. Rate likelihood and impact, then link to the control that addresses the threat. Update after every significant change. -->

### 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 \times I, \quad L, I \in \{1, 2, 3, 4, 5\}
$$

with High at $R \ge 15$, Medium at $8 \le 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

<!-- Guidance: Testable statements derived from objectives and threats. Each has a verification method. Avoid restating policy in general terms. -->

| 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

<!-- Guidance: Cover human users (customers, staff), workloads and machines. Describe authentication, authorisation model, lifecycle and privileged access. -->

### 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

<!-- Guidance: Classification, encryption in transit and at rest, key management, minimisation and retention. Tie each control to an asset. -->

### 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

<!-- Guidance: Describe zones, what may talk to what, and the controls at each boundary. Default deny. -->

| 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

<!-- Guidance: How the software is built securely: secure development lifecycle, coding controls and dependency management. -->

| 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

<!-- Guidance: Where secrets live, who can read them, how they rotate and how leaks are detected. No secrets in code, images or environment files in repositories. -->

| 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

<!-- Guidance: What is logged, where it goes, how long it is kept and which detections run. Logs must not contain secrets or unnecessary personal data. -->

| 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

<!-- Guidance: How this system plugs into the organisation's incident response process. Name contacts, playbooks and the evidence available. -->

| 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

<!-- Guidance: Every external service that touches assets in section 2. Record what it receives, the assurance obtained and the exit plan. -->

| 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

<!-- Guidance: Map obligations to the controls in this document. Name the framework and clause only when you are sure of it; let the compliance function confirm. This is a format, not legal advice. -->

| 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

<!-- Guidance: Show that every high threat is addressed, list what remains, and record who accepted it and until when. -->

### 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

<!-- Guidance: Glossary, references and supporting artefacts. -->

### 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.