Cybersecurity Engineering Handbook / Chapter 60
System Security Profile Template
Create a compact system security profile that connects architecture, data, identity, controls, threats, operations, and evidence.
Preparing audio…
Audio edition
System Security Profile Template
The Customer Export Service looks simple on its context diagram: an API accepts a request, a worker builds an archive, and object storage holds it until download. That picture does not tell a reviewer whether the worker preserves tenant identity, who may fetch the archive, how long it survives, or which release proves that cross-tenant reads are denied. The answers exist, but they are divided among code, service catalogs, threat models, runbooks, and test results.
A system security profile joins those answers without trying to replace their sources. It is a maintained index of the facts and decisions that determine a system’s security: what is in scope, where trust changes, which requirements apply, how they are implemented, who operates them, what evidence can fail, and which risks remain.
The profile is a map, not a warehouse
Keep the profile short by pointing to authoritative artifacts rather than pasting them into the document. A versioned data-flow diagram belongs in the architecture record. Detailed attacker paths belong in threat scenarios. Normative obligations belong in the requirement catalog. Test output belongs with the release or assurance record. The profile names the current artifact, explains why it applies, and traces it to the system decision under review.
That trace is more valuable than a long inventory. “Uses OAuth” names a technology. “Browser administrators authenticate through the company identity provider using OIDC with PKCE; the API validates issuer and audience; AUTHN-USER-003 is verified by the release authentication suite” exposes an identity path, a requirement, an enforcement point, and evidence.
Create the first profile while the architecture can still change. Refresh it when ownership, exposure, sensitive data, identity, authorization, tenant boundaries, critical dependencies, recovery duties, or important threat scenarios change. An incident or failed control should also reopen it. A calendar review may catch neglect, but elapsed time alone does not describe what became unsafe.
Establish the review boundary first
The first hard decision is what the profile describes. “Data Platform” is too broad if several services have different owners and trust boundaries. “Export API” is too narrow if a background worker and object store can disclose the same records.
For the Customer Export Service, the review boundary includes the public export API, request queue, export worker, archive bucket, download path, and the identities and keys that connect them. The shared identity provider and audit platform are dependencies outside that boundary. Their guarantees still matter, but their internals belong to their own profiles.
State exclusions as carefully as inclusions. If billing exports use a separate service, name that exclusion and link to its profile. Otherwise a reader may mistake silence for coverage.
A profile template
Use the headings that fit the system, but preserve the chain from system fact to decision and evidence. Omit a field only when it is genuinely inapplicable, and say why when the omission could be mistaken for missing work.
# System Security Profile: <system name>
## Document control
- Profile ID and version:
- Accountable system owner:
- Security contact and escalation route:
- System or release version represented:
- Last reviewed by and date:
- Review triggers since the previous version:
- Open decisions and due owners:
## Purpose, scope, and criticality
- Business capability and primary users:
- Included components, environments, and interfaces:
- Explicit exclusions and linked profiles:
- Criticality and assurance level, with rationale:
- Availability and recovery obligations:
## Architecture and dependencies
- Versioned system-context and data-flow diagrams:
- Ingress, egress, administrative, batch, and callback paths:
- Named trust boundaries and policy-enforcement points:
- Critical internal and third-party dependencies:
- Failure behavior when each critical dependency is unavailable:
## Data and assets
- Sensitive data and capabilities, with classification:
- Sources, stores, transformations, logs, backups, exports, and destinations:
- Retention, deletion, and recovery behavior:
- Encryption and key ownership:
- AI or model use, including data and tool boundaries:
## Actors, identities, and access
- Human, administrator, workload, partner, and third-party actors:
- Authentication and session boundaries:
- Authorization model and tenant-isolation rule:
- Service identities and credential delivery:
- Privileged and emergency access, approval, observation, and revocation:
## Threat and control trace
- Dominant threat-scenario IDs:
- Applicable requirement-catalog IDs:
- Implementation and enforcement points for each requirement:
- Verification capable of showing failure:
- Detection and first response decision:
- Residual risks and active exception IDs:
## Secure operation and recovery
- On-call and security-alert owners:
- Security telemetry, routing, and retention:
- Vulnerability, dependency, patch, and release responsibilities:
- Incident, containment, restore, and decommissioning runbooks:
- Recovery target and latest successful restore exercise:
## Evidence index
- Architecture and threat-model review records:
- Attributed security and negative-test results:
- Release review and deployed-version record:
- Access review, restore exercise, and detection-test records:
- Active exceptions and risk decisions:
## Change triggers
- System events that require this profile to be reviewed:
The template deliberately asks for enforcement points as well as controls. A statement that storage is private is not enough if a signed URL bypasses the download service. A statement that tenant authorization exists is not enough if the API checks it but the worker trusts a tenant identifier copied from the request body.
Follow one decision through the profile
The export service’s most consequential question is whether one tenant can obtain another tenant’s archive. A useful profile lets a reviewer follow that question through the system without reconstructing it from interviews.
# System Security Profile: Customer Export Service
## Document control
- Profile ID and version: SSP-EXPORT-007, version 4
- Accountable system owner: Customer Data Platform service owner
- Security contact and escalation route: Product Security on-call through
SEC-ESC-01
- System or release version represented: export-service 2026.07.3
- Last reviewed by and date: release reviewer, 2026-07-16
- Review triggers since the previous version: downloads moved behind the
Export API; archive lifetime reduced from 24 hours to 4 hours
- Open decisions and due owners: EXC-EXPORT-012 permits the legacy worker
credential until workload-identity migration; platform identity owner;
expires 2026-08-15
## Purpose, scope, and criticality
- Business capability and primary users: account administrators request and
download archives of their tenant's customer records
- Included components, environments, and interfaces: production Export API,
request queue, export worker, archive bucket, and authenticated download path
- Explicit exclusions and linked profiles: the company identity provider and
audit platform are governed by SSP-IDENTITY-002 and SSP-AUDIT-004
- Criticality and assurance level, with rationale: high, Level 2; compromise
can disclose regulated records across tenants
- Availability and recovery obligations: requests may pause during dependency
failure; existing archives remain unavailable rather than bypassing access
checks; RTO 24 hours and RPO 0 because jobs can be recreated from source data
## Architecture and dependencies
- Versioned diagrams: export-context-v6 and export-data-flow-v9 in ADR-EXPORT-14
- Trust boundaries and enforcement points: the API derives tenant ID from the
authenticated subject before enqueue; the worker verifies the signed job
envelope; the download API authorizes subject, action, archive, and tenant
before issuing a five-minute single-object URL
- Critical dependencies: company identity provider, request queue, object
storage, key service, customer-record service, and audit platform
- Dependency failure: failed identity, key, or authorization checks deny the
request; failed audit delivery stops archive download and pages the service
owner after the bounded retry queue is exhausted
## Data and assets
- Sensitive data: tenant-scoped customer records classified Restricted;
archive object keys and download URLs are treated as secrets
- Data path: Customer Records API to worker memory to encrypted archive bucket
to authenticated download; metadata and authorization outcomes go to the
audit platform
- Retention and deletion: archives expire after four hours by bucket lifecycle;
successful and failed deletion events are monitored; source records follow
the Customer Records retention policy
- Logs: tenant-safe identifiers, actor ID, action, archive ID, policy result,
and release version; no record contents or download URLs
## Actors, identities, and access
- Human actor: an account administrator authenticated by the company identity
provider with MFA
- Authorization: `AUTHZ-EXPORT-004` requires account-administrator permission
and object-level tenant membership for create, status, download, cancel, and
delete actions
- Workload identity: the API and worker use separate identities; only the
worker may write archives, and only the download service may mint object URLs
- Privileged access: production access uses approved just-in-time elevation,
session recording, and the ACCESS-PROD control family
## Threat and control trace
- Threat scenario: TS-AUTHZ-EXPORT-002, cross-tenant archive disclosure through
a forged tenant identifier or archive ID
- Controls: AUTHZ-EXPORT-004 for every archive action; DATA-EXPORT-002 for
classification, expiry, and deletion; LOG-AUTHZ-003 for attributable policy
decisions
- Verification: release suite `export-tenant-boundary` changes subject, tenant,
archive, and action independently and expects denial; the worker-envelope test
rejects altered tenant context; the download test rejects expired URLs
- Detection and response: repeated denials, subject/job tenant mismatch, or
unusual export volume alert the Product Security on-call; the first
containment decision is whether to disable new exports while preserving API,
queue, worker, and object-access evidence
- Residual risk: a compromised legitimate tenant administrator can export the
records that role is authorized to access; MFA, volume detection, four-hour
expiry, and customer incident procedures reduce but do not eliminate it
## Evidence index
- Architecture decision: ADR-EXPORT-14 at revision 8
- Threat review: TM-EXPORT-2026-03, scenarios 2, 4, and 7
- Security tests: CI run 88421 for release 2026.07.3, suite
`export-tenant-boundary`
- Deployed-version record: production attestation DEPLOY-EXPORT-2026-07-16-03
- Detection test: DET-EXPORT-009 simulation result from 2026-07-15
- Active exception: EXC-EXPORT-012 with owner, compensating controls, expiry,
and migration task
Notice what the profile does not claim. A private bucket does not prove tenant authorization. Passing API tests does not prove that the worker preserves tenant context. A link to a test folder does not identify evidence for the deployed release. Each claim names the narrower artifact that can support or contradict it.
Review from three operating positions
First read as a release reviewer. Can you identify the deployed boundary, the catalog requirements that apply, the enforcement points, and evidence attributed to this release? If an exception exists, can you find its owner, compensating controls, expiry, and replacement work?
Then read as an incident responder who has received an alert for unusual export volume. The profile should reveal the sensitive asset, identity and tenant paths, logs that preserve the relevant decisions, the first containment choice, and the owner who can act. It should not require the original designer to explain which queue, worker, or bucket belongs to the service.
Finally, read as the next engineer changing the system. A new delivery channel, tenant model, privileged path, data class, third-party destination, or failure behavior should be recognizable as a review trigger. If the engineer cannot tell which profile sections and linked artifacts the change invalidates, the document records a snapshot but does not govern its own maintenance.
Keep it current through events
Version the profile with the system or in a knowledge base that preserves review history. Give one role responsibility for resolving conflicting facts and requesting review; do not assign “maintenance” to an unbounded group.
Prefer observable triggers to ceremonial refreshes. A deployment that adds egress, a schema change that introduces Restricted data, a new administrative action, an ownership transfer, an incident, a failed restore, an expired exception, or retirement of a critical dependency should open a profile review. Automation can flag changed dependencies, diagrams, catalog IDs, or evidence links, but an owner must decide whether the security model changed.
Delete stale claims instead of carrying them forward with a new review date. The profile is ready when an engineer unfamiliar with the system can locate its boundary, follow a dominant threat to its controls and release evidence, operate the first response decision, and see what change would make those answers untrustworthy.