In this chapter
10.1 Security is a responsibility model
Authentication proves a presented identity according to a mechanism. Authorization decides what that actor may do to a particular object in a particular context. Encryption protects selected communication or storage boundaries. None of these mechanisms alone establishes institutional trust. The example requires explicit boundaries between users, application services, administrators, storage and recovery copies. A locally hosted system can still expose data through logs, telemetry, support exports or backup destinations. Data sovereignty therefore needs an information-flow and responsibility assessment, not only a server-location statement.
10.2 Trust and information boundaries
| Boundary | Control objective | Evidence |
|---|---|---|
| User to application | Authenticated, scoped and permitted action | Wrong-department and revoked-access tests |
| Application to storage | Least privilege and controlled changes | Service permissions and migration review |
| Administrator to infrastructure | Accountable privileged access | Named access, rotation and change trail |
| System to external service | Approved data disclosure | Contract, field inventory and destination review |
| Backup to recovery environment | Confidential and usable recovery copy | Access controls and authorized restore |
10.3 Threat-informed design
For a request approval, consider identity misuse, cross-department action, replay, changed content and unauthorized evidence alteration. Identify the asset, actor, entry point and plausible consequence. Prioritize controls against the agreed scenario rather than claiming coverage of every possible threat. A detailed threat review must include account recovery, service credentials, administrative access, audit access and incident response. Do not store raw credentials or sensitive personal records in application logs. Redaction, retention and access review belong in the operating design.
10.4 Sovereignty and supplier responsibility
The data owner approves classification, permitted locations and uses. Legal or policy authority determines applicable obligations; the architect records the requirement and its design consequence. The supplier provides evidence that the agreed boundaries are implemented and identifies subprocessors or external destinations where relevant. A claim of “fully local” is not accepted until backups, identity services, email, monitoring, developer access and support paths are examined. Conversely, local hosting is not by itself a security guarantee. Capacity to patch, monitor and recover matters.
10.5 Security acceptance
The design package contains a trust-boundary view, access matrix, secrets lifecycle, retention decisions, incident escalation and a test scope. Acceptance requires permitted and forbidden journeys, evidence of access removal and a protected recovery exercise. Unresolved risks have named owners and explicit treatment decisions.