Build Security and Governance Into Delivery

Security does not arrive when a reviewer opens a checklist. Governance does not arrive when a committee name appears on a diagram.

They exist when a deployment can answer, with evidence:

• what must be protected and why;
• what can go wrong, through which path, and with what consequence;
• which control objective addresses that risk;
• where the control is implemented;
• how the implementation is verified;
• what evidence the verification produced;
• who owns operation and remediation;
• which designated authority approves the residual risk or exception.

An FDE helps build this chain while the system is still changeable. The FDE does not become legal counsel, privacy officer, security approver, safety authority, independent auditor, accessibility authority, or business risk owner. Outcome ownership means making a decision ready for the correct authority, not absorbing authority that was never delegated. [CLM-078]

Start with consequence, not framework names

The fictional Orchid Assist deployment has a bounded purpose: help qualified technicians identify equipment, retrieve approved evidence, and consider next inspection steps. It also has concrete exposure:

• a person could act on evidence for the wrong equipment;
• one customer or region could see another’s records;
• an unqualified actor could approve a safety-relevant step;
• a secret could be placed in configuration or a log;
• an interface could retry an action whose completion is unknown;
• an obsolete manual could be presented as current;
• a model could invent support, follow untrusted instructions, or request an unauthorized tool;
• the system could become unrecoverable because emergency access depends on the failed control plane;
• audit collection could preserve more sensitive content than the business purpose requires;
• an inaccessible review interface could prevent a user from examining evidence or exercising a required decision.

These statements are more useful than “follow NIST,” “be zero trust,” or “meet OWASP.” A framework can organize questions and desired outcomes. It cannot know Orchid’s actual assets, actors, deployment boundary, contractual obligations, regional rules, safety consequence, control implementation, or decision authority.

Use frameworks as versioned lenses. Record the selected scope, mapping, evidence, gap, and accountable owner. Never turn alignment into certification language. NIST CSF 2.0 is an outcome-oriented framework, not a prescribed implementation or certificate. [CLM-069]

Build the evidence chain

Use this sequence:

1. Asset or obligation. What has value or must be preserved: equipment identity, technician authorization, customer records, service availability, safe workflow state, evidence provenance, secrets, audit integrity.
2. Threat or failure condition. What actor, event, defect, dependency, misuse, or operational condition could cause loss?
3. Risk statement. Under a defined context, what could happen, to whom, and with what consequence?
4. Control objective. What must be prevented, detected, contained, recovered, or decided?
5. Implementation. Which code, configuration, workflow, process, training, physical measure, or contractual boundary realizes that objective?
6. Verification. Which inspection, analysis, test, exercise, review, or monitoring query challenges the implementation?
7. Evidence. Which versioned result shows what happened, in which environment, at what time, with which limits?
8. Owner disposition. Who operates/remediates the control, and which designated authority approves, rejects, restricts, or accepts an exception?

This is an original synthesis structure for FDE delivery, not a formal external standard. [CLM-075]

Write risks as decisions can use them

Avoid vague entries such as “data breach,” “AI risk,” or “API security.” A useful statement identifies condition, consequence, and affected obligation:

If a support identity can read equipment records across tenants, a compromised or misused credential could disclose another customer’s operational data, violating the isolation expectation and expanding incident scope.

Do not pretend an ordinal score is objective. Likelihood, consequence, detectability, exposure, and risk tolerance depend on context and owner judgment. If the customer uses a scoring method, record the method/version, inputs, uncertainty, owner, and decision rule. Preserve narrative consequence even when a number exists.

Separate inherent, controlled, and residual views

• Inherent view: the condition before the proposed control set.
• Controlled view: expected condition if the controls operate as designed.
• Residual view: what remains after evidence and known limitations.

The residual view is not “low” because a control appears in a spreadsheet. It depends on implementation and evidence. A missing negative test, untested recovery path, unowned alert, or unsupported environment can keep material uncertainty open.

Turn a vague control into a verifiable record

“Use least privilege” is a control intention. “Encrypt data” is a mechanism. “Require approval” is a workflow statement. None is complete evidence.

A control record needs:

Field	Question
control ID/version	Can evidence and change history identify the same control?
risk/control objective	What consequence must be prevented, detected, contained, recovered, or decided?
scope	Which actors, resources, operations, tenants, regions, environments, and states?
implementation	Which actual enforcement point, configuration, process, and responsible component?
verification	Which positive, negative, boundary, failure, and recovery tests?
evidence	Which immutable-enough result, version, environment, time, and limitations?
operating owner	Who keeps it working and responds to failure?
decision authority	Who can approve the residual condition or exception?
monitoring/review	Which signal, cadence, trigger, retention, and escalation?
known gap/expiry	What remains uncertain, and when must the decision be revisited?

A framework label or policy sentence becomes useful only when it connects to implementation, verification, evidence, ownership, and disposition. [CLM-076]

Example: qualified approval

Risk. A technician without the required qualification approves a safety-relevant next step for the wrong region/equipment family.

Objective. Only a currently qualified, region-authorized actor who is not the requester can approve that step for the bound equipment.

Implementation. The authorization service evaluates principal, tenant, region, equipment family, operation, qualification, expiry, and requester/approver separation. The workflow rejects missing/expired/mismatched grants. The UI displays evidence and does not default to approve.

Verification. Test a valid approval plus wrong tenant, wrong region, wrong equipment family, expired qualification, requester-equals-approver, ambiguous equipment, and authorization dependency unavailable. Inspect server-side enforcement rather than UI visibility alone.

Evidence. Record test bundle version, policy version, environment, results, failed cases, reviewer, and open limitations. Do not copy sensitive payloads into the report.

Owners. The identity/platform owner operates enforcement. A designated safety/business authority defines the qualification and accepts residual workflow risk. The FDE prepares and routes evidence.

Threat-model the workflow and system together

A component-only threat model misses handoffs. A workflow-only model misses trust boundaries. Join OA-02 workflow states and OA-05 architecture.

For each state transition ask:

• Who initiates it, under which identity?
• Which resource, tenant, region, and operation are involved?
• What evidence binds the request to the correct equipment and customer?
• What untrusted input can influence the decision?
• What happens if an interface times out, duplicates, reorders, or returns stale data?
• What privilege changes the workflow state?
• Which information is read, derived, stored, transmitted, logged, cached, or exported?
• Which detection would reveal misuse or control failure?
• Can the system contain impact and recover without widening routine access?
• Who has authority to stop, override, or accept the condition?

Use misuse, failure, and recovery cases. A malicious actor is not required for harm: an expired role, misbound tenant, copied secret, stale index, broken clock, partial deployment, inaccessible UI, or exhausted reviewer can create the same consequence.

Model trust per request

Network placement is not identity. A private subnet, VPN, VPC, or IP allowlist can reduce exposure, but it does not prove the user, workload, tenant, resource, action, or current authority. Zero trust architecture focuses protection on resources and rejects implicit trust based only on network location. [CLM-067]

For Orchid, authorization evaluates:

principal + resource + operation + tenant + region + qualification + context + expiry

The decision is enforced near the resource/action, not only in the browser. Service identities receive separate grants from human users. Support access is time-bounded, purpose-bound, recorded, and revocable. Cache and search layers preserve tenant/region boundaries rather than assuming the calling UI filtered correctly.

Where OAuth 2.0 is actually used, record the flow and apply RFC 9700 security best current practice to that context. The protocol name itself is not a security outcome. [CLM-068]

Minimize data across the entire path

“We do not store it” is incomplete. Data may still appear in requests, queues, memory, logs, traces, analytics, caches, backups, search indexes, model inputs, grader datasets, support exports, screenshots, or incident artifacts.

Create a data-handling record for each category:

• purpose and prohibited secondary use;
• data subject/owner and source/provenance;
• classification/sensitivity;
• fields required, derived, or explicitly excluded;
• collection/input path;
• storage/cache/index/backup locations;
• tenant and regional boundary;
• access roles and approval;
• transmission and processor/subprocessor path;
• retention, expiry, deletion, and legal hold owner;
• logging, trace, evaluation, support, and export treatment;
• encryption/key responsibility where applicable;
• verification and incident contact;
• unresolved legal/privacy decision and designated authority.

Minimization is a design activity. Prefer an equipment identifier plus approved evidence references over an unrestricted ticket transcript. Prefer a derived eligibility flag over a full qualification dossier when the consumer only needs the decision. Prefer allowlisted audit fields over raw request bodies.

The NIST Privacy Framework can structure privacy risk conversations, but it is not legal advice or a jurisdiction-specific compliance decision. [CLM-071]

Design auditability without creating a second exposure

An audit event should let an authorized investigator reconstruct the consequential decision path without turning the audit system into a copy of all operational data.

Useful event fields may include:

• stable event ID and timestamp/time source;
• actor/workload ID and authentication context reference;
• action and resource ID;
• tenant/region and environment;
• request/intent/correlation ID;
• policy/control/version decision;
• result/reason code;
• approval or exception reference;
• evidence/model/retrieval bundle reference where relevant;
• integrity, retention, and access metadata.

Avoid raw secrets, credentials, full documents, unrestricted prompts, sensitive free text, and entire payloads by default. Use references, classifications, hashes where appropriate, and narrowly approved enrichment. Restrict who can query/export audit data. Test tenant isolation, retention, clock behavior, event loss/duplication, redaction, and investigation usability.

More logging is not automatically more accountable. Excess content increases privacy and security exposure and can make useful signals harder to find. Audit collection must remain purpose-bound and minimized. [CLM-077]

Treat secrets and keys as operational systems

Do not place secrets in source, example configuration, test fixtures, tickets, prompts, logs, screenshots, or runbooks. A secret reference is not enough unless runtime identity, retrieval, rotation, revocation, audit, availability, and break-glass behavior are designed.

Record:

• secret/key owner and allowed workloads;
• environment and tenant/region scope;
• creation, distribution, storage, use, rotation, expiry, and revocation;
• deployment and rollback behavior during rotation;
• detection for unauthorized use or disclosure;
• recovery when the secret manager or identity dependency is unavailable;
• evidence that old material no longer authorizes access.

Never copy a real secret into a test to prove redaction. Use synthetic canaries and scanning. If a scanner finds a credential, treat rotation/revocation and exposure assessment as separate from removing the string.

Separate duties where consequence requires it

Separation of duties prevents one identity from initiating, approving, executing, and concealing a consequential action. Apply it proportionately:

• code author versus protected-branch/release approval;
• access requester versus approver;
• safety-step requester versus qualified approver;
• exception proposer versus accepting authority;
• audit producer versus evidence reviewer where independence is required.

Avoid cargo cult separation. If a team is small, the accountable owner may select compensating controls such as time delay, two-person review, immutable audit, limited scope, heightened monitoring, or post-action review. The FDE documents options and evidence; the owner decides.

Design break-glass as a different controlled path

Emergency access is not “admin without rules.” Define triggering conditions, eligible actors, approval where feasible, scope, duration, authentication independent enough to survive the incident, actions allowed, notification, recording, post-use review, credential rotation, and recurring exercise.

Test break-glass under the failure it is meant to survive. If the access system, control plane, DNS, network, or secret manager is down, a recovery path that depends on it is fictional. At the same time, do not weaken routine controls merely to simplify a rare emergency.

Integrate security into the development lifecycle

Security work begins before code and continues through support:

1. Discovery: obligations, assets, users, abuse/failure, authority, data/access minimization.
2. Architecture: trust/data/failure boundaries, identity, tenancy, region, secrets, recovery.
3. Contracts: validation, semantics, authorization, idempotent intent, error/reconciliation.
4. Implementation: secure defaults, dependency/source integrity, code/config review, tests.
5. Verification: positive/negative/boundary/failure/recovery checks in representative environments.
6. Release: evidence bundle, known gaps, decision owner, exposure/ramp/rollback.
7. Operation: monitoring, incident/support paths, access review, patch/change, evidence refresh.
8. Retirement: revoke access, dispose data, remove integrations, preserve required records.

NIST SSDF 1.1 supports integrating secure practices across the lifecycle instead of postponing security to a final gate. Cite the final version in use; do not silently substitute draft or later guidance. [CLM-070]

Use verification standards carefully

OWASP ASVS 5.0.0 provides versioned application-security verification criteria. Select relevant scope and level with security ownership; preserve IDs/version in mappings; connect each selection to implementation and evidence. “ASVS aligned” without scope, version, results, gaps, and authority is not a useful release claim. [CLM-072]

WCAG 2.2 provides testable web accessibility success criteria. Automated checks can find some failures, while keyboard use, focus order, semantics, screen-reader behavior, zoom/reflow, error recovery, cognitive load, and real task completion require additional inspection and user evidence. Conformance alone does not prove complete usability or accessibility for every person and context. [CLM-073]

ISO/IEC 25010:2023 records a product quality model useful for remembering that security, reliability, performance efficiency, interaction capability, maintainability, flexibility, and safety-related qualities can interact. This book does not reproduce the copyrighted requirements. The practical point is that one quality attribute cannot erase the others. [CLM-079]

Keep AI inside the same governance chain

AI does not receive a separate, weaker definition of evidence. Begin with the Chapter 9 decision record and add system threat paths:

• untrusted retrieved content influences output or tool choice;
• one tenant’s content enters another tenant’s context;
• sensitive data enters prompts, traces, graders, or provider retention;
• a model invents evidence, hides uncertainty, or suggests a prohibited action;
• a tool request exceeds identity/tenant/region/operation scope;
• evaluation data is poisoned, leaked, or unrepresentative;
• reviewer workload makes approval nominal;
• model/prompt/index/policy changes invalidate prior evidence;
• latency/cost exhaustion removes the safe fallback.

Controls live across data selection, identity, retrieval, model interface, output schema, deterministic policy, authorization, qualified review, tool execution, audit, evaluation, monitoring, and stop/rollback. Prompt instructions alone are not an enforcement boundary.

NIST AI RMF 1.0, its Generative AI Profile, and current community guides can prompt discovery. They are versioned and incomplete for a specific deployment. They do not replace the system threat model or create certification. [CLM-074]

For Orchid, AI is still limited to evidence summary/ranking. No model output accepts safety risk, approves a safety step, widens access, bypasses tenant/region boundaries, or orders a part.

Map authority before an exception appears

Create an authority map for each consequential decision:

Decision	Evidence preparer	Consulted owner	Designated authority	FDE boundary
access scope	engineering/FDE	identity/security/data owners	named access authority	propose/test; cannot self-grant
regional data handling	engineering/FDE	privacy/legal/security	named organizational authority	map flow/gaps; no legal conclusion
safety workflow	engineering/FDE	domain/safety owner	designated safety/business authority	implement evidence path; no safety acceptance
security exception	engineering/FDE	control/system owner	security/risk authority	options/evidence; no self-approval
accessibility release	product/engineering	accessibility/user owner	designated release authority	test/remediate; no universal conformance claim
production exposure	delivery/product/operations	all relevant owners	named business/release authority	recommend cohort/stop; no unilateral risk acceptance

The map must name actual roles or groups in the customer context, delegation scope, quorum if relevant, response time, escalation, expiry, and substitute. A generic “security approved” field is weak if no accountable identity, scope, date, evidence bundle, or conditions are recorded.

Make exceptions expire

An exception record contains:

• exact control/risk/scope;
• reason and alternatives considered;
• evidence and uncertainty;
• affected users/data/environments;
• compensating controls;
• monitoring and incident trigger;
• accepting authority and delegation basis;
• decision date, expiry, review trigger;
• remediation owner and target;
• automatic restriction when expired where feasible.

“Temporary” without expiry and owner means permanent by accident. An ownerless exception is an unresolved blocker, not approval.

Complete Orchid’s OA-05 governance section

The design dossier now records:

Threat and risk model

Assets: equipment binding, approved evidence, customer isolation, qualified authority, workflow state, secrets, audit integrity, availability/recovery.

Principal conditions: identity misuse, cross-tenant/region access, stale/malicious evidence, interface ambiguity, excessive privilege, secret exposure, model/tool misuse, log overcollection, reviewer failure, recovery dependency.

Risk entries preserve consequence, affected obligation, exposure, existing/proposed controls, verification, uncertainty, operating owner, and decision authority.

Control matrix

Every selected control has objective, scope, implementation, positive/negative/failure/recovery verification, evidence reference, owner, monitoring, gap, and formal disposition. Framework mappings are secondary metadata, not the control itself.

Data-handling record

Orchid accepts confirmed equipment/context and approved evidence references. It excludes unrestricted customer archives by default. Tenant/region boundaries apply to operational storage, retrieval, cache, audit, evaluation, support export, and backup. Retention/deletion and legal questions remain explicitly owner-routed.

Access and secrets

Human/workload identities are separate. Authorization binds resource, operation, tenant, region, qualification, and expiry. Support elevation is purpose/time bounded. Configuration contains secret references, never secret values. Rotation/revocation and dependency failure are tested.

AI controls

AI remains suggestion-only. Confirmed equipment, allowlisted evidence, deterministic policy, qualified approval, segmented evaluation, budget fallback, version bundle, and kill/rollback bound behavior.

Evidence plan

The plan includes contract tests, authorization denials, tenant/region isolation, environment/config/secret checks, dependency/static analysis, AI critical-segment cases, audit redaction, break-glass exercise, accessibility evidence, failure/recovery tests, and owner review.

The executable companion adds four tests: documentation-only control failure, evidence-pending-approval, designated/scope-bounded authority, and allowlisted/redacted audit events. These tests demonstrate the boundary; they do not certify a production system.

Run a control-evidence review

For each control, ask:

1. Is the risk/consequence specific enough to choose a control?
2. Is the objective stated independently of one tool?
3. Is enforcement actually in the path that matters?
4. Does verification include denied, boundary, dependency-failure, and recovery cases?
5. Does evidence identify version, environment, time, and limitations?
6. Can the operating owner detect and remediate failure?
7. Is the formal authority named and within delegated scope?
8. Does an exception expire and restrict exposure?
9. Could the control itself create availability, privacy, accessibility, or support harm?
10. What change would invalidate the evidence?

If the answer to 3 or 4 is no, the control is probably documentary. If 6 or 7 is no, the decision is ownerless. If 10 is unknown, evidence can silently become stale.

Common governance failures

Checklist theater

Symptom: every row is green because a document exists.

Repair: objective, implementation, verification, evidence, owner, disposition, and limitations.

Framework-name compliance

Symptom: “NIST/OWASP compliant” without version, scope, mapping, tests, gaps, or authority.

Repair: use versioned selections as lenses; remove certification language unless a qualified formal process supports it.

Security at the final gate

Symptom: architecture/data/access choices are already expensive to change.

Repair: lifecycle integration, incremental evidence, and explicit stop decisions from discovery onward.

Excessive access for delivery speed

Symptom: shared admin credentials or broad production copies become the default discovery path.

Repair: question-bound access, synthetic/minimized evidence, workload identities, time-bound elevation, revocation, audit.

Logging everything

Symptom: sensitive payloads/prompts/documents accumulate in a broadly searchable system.

Repair: purpose-based event schema, allowlist/redaction, access/retention/export controls, investigation usability tests.

Human approval theater

Symptom: reviewer lacks qualification, evidence, time, interface support, or authority.

Repair: qualification/scope checks, evidence-first UI, workload measurement, separation where needed, fallback/escalation.

Ownerless exception

Symptom: “business accepted” without a named delegated authority, expiry, or compensating control.

Repair: block exposure or route a complete decision record.

Break-glass that shares the broken dependency

Symptom: emergency recovery cannot authenticate or reach the control plane during the target failure.

Repair: scenario-based exercise, limited independent path, notification, post-use review, and rotation.

Exercise: repair five controls and route two decisions

Start with these vague statements:

1. “Use encryption.”
2. “Only authorized users can approve.”
3. “Keep logs for audit.”
4. “Follow OWASP for the AI.”
5. “Have a break-glass account.”

For each, produce:

• contextual risk and consequence;
• control objective and scope;
• implementation/enforcement point;
• positive, negative, failure, and recovery verification;
• evidence/version/environment/limitations;
• operating and remediation owner;
• formal decision authority;
• monitoring, expiry, and invalidation trigger.

Then route:

• a temporary regional logging exception;
• a production exposure decision with an unresolved break-glass exercise.

Pass only if the FDE prepares evidence and alternatives without fabricating approval. If the required authority is absent, record the decision as blocked or restrict the exposure. Do not convert silence into acceptance.

The Chapter 10 gate

Before implementation begins, OA-05 must include:

• workflow/system/AI threat and risk model;
• risk-to-control-to-implementation-to-verification-to-evidence chain;
• data-handling and minimization record across logs, traces, support, evaluation, and backups;
• human/workload identity, least privilege, tenant/region, secrets, and separation design;
• audit event purpose, schema, access, retention, redaction, and investigation path;
• secure development and representative verification plan;
• AI-specific threats connected to deterministic/system/human controls;
• break-glass and recovery boundaries;
• versioned framework mappings with gaps and no certification language;
• named operating owners and formal decision authorities;
• exception/expiry/escalation path;
• passing companion governance tests.

The gate passes when every material control can be traced to an implementation and verification plan, every open risk has an owner and disposition path, and the FDE’s evidence role remains distinct from formal approval.

Chapter 11, Build a Production Vertical Slice, will build one vertical slice under these constraints. It will not postpone identity, failure behavior, observability, accessibility, rollback, or control evidence until after the happy path works.