October 24, 2026

Security Requirements That Actually Work — Part 3: From Requirements to Release: AWS Baselines and…

Part 3 of 3 in the series “Security Requirements That Actually Work”

By John Zhang

10 min read

Two worked AWS examples, and how to stop your delivery framework and your architecture framework from working against each other.

Parts 1 and 2 gave you the theory: four approaches to sourcing requirements, a two-layer threat model, and a clear ownership model with an encryption example.

But theory does not ship. This last part is about the two places where good requirements usually die:

  • In the platform and the application, where "what" has to become something an engineer can build and an auditor can verify.
  • In the delivery process, where the project clock and the architecture process pull in different directions.

In this part:

  • An AWS platform baseline (the inherited layer).
  • A Payment Initiation API (the designed layer), traced from business risk to test evidence.
  • PMO vs. TOGAF ADM: the trap of using either alone, and how to use both.
  • Four golden rules to take away.

A quick note: these are my own views, based on public frameworks and my experience. They do not describe how any one organization works, including mine. Both scenarios are made up for illustration. They are not official AWS or CIS benchmarks, and using them does not mean you comply with any law.

Example A: an AWS platform security baseline

Scenario: a large enterprise builds a governed AWS platform for internal apps, customer APIs and services handling confidential data. The governance and platform approaches do most of the work here, and the business-driven approach sets "how much."

Each item follows one pattern: What (the outcome), How (acceptable options), Evidence. Here are the key ones:

  • PL-01, Governance boundary. What: production runs inside an approved boundary with controlled account creation and separate environments. How: AWS Organizations, Control Tower, organization policies. Evidence: account list, policy tests, provisioning records.
  • PL-02, Identity. What: people and workloads have traceable identities, least privilege and separation of duties; long-lived credentials are minimized. How: IAM roles, federation, temporary credentials, permission boundaries. Evidence: IAM policy analysis, automated tests, access reviews.
  • PL-03, Encryption and keys. What: data is encrypted at rest and in transit by tier; for higher tiers, key administration is separate from data administration. How: built-in storage encryption, KMS, TLS at approved versions. Evidence: configuration scans, key-policy review.
  • PL-04, Network. What: reach and outbound traffic are limited to approved flows; public exposure is intentional and reviewed. How: private subnets, security groups, network firewalls, VPC endpoints. Evidence: reachability analysis, exposure list.
  • PL-05, Logging. What: security activity is logged, protected from tampering and available for investigations. How: organization-level CloudTrail, a central protected log archive. Evidence: coverage tests, immutability settings, investigation drills.
  • PL-06, Configuration baseline. What: production settings are checked against approved baselines, and drift is handled. How: AWS Config, Security Hub, CI policy checks. Evidence: benchmark reports, fix records.
  • PL-07, Secure delivery. What: changes pass security checks matched to workload risk. How: CI/CD gates with code, dependency, IaC and container scanning. Evidence: pipeline results, release evidence.
  • PL-08, Detection and recovery. What: critical workloads have detection, response and recovery matched to business impact. How: alerting, playbooks, backups, multi-AZ design. Evidence: alert tests, exercise reports, recovery results.
  • PL-09, Exceptions. What: important exceptions have a risk owner, a reason, compensating controls and an end date. How: GRC workflow, exception register, expiry tracking. Evidence: approved record, expiry alerts.

(The full baseline would also list alignment to CSF, ISO and Well-Architected for each item. I keep that off this page to stay readable.)

Three things to notice:

  • The "what" is separate from the "how." PL-03 does not say "use KMS customer keys." KMS is one allowed option.
  • The evidence matters. It fixes the mistake of confusing a control that exists with a control that works. A logging policy does not prove every event is captured, and a recovery plan does not prove you can recover in time.
  • Benchmarks cover only part of it, on purpose. The CIS page currently lists AWS Foundations Benchmark 7.1.0, and a CIS update post mentions v7.0.0. Pin a version and recheck before you standardize. Passing it supports PL-06. It does not prove PL-02, and it says nothing about authorization inside an app.

Sort platform rules into three groups

So teams know what is negotiable:

  • Group A, not negotiable: approved account setup, audit logging, no public exposure by default, privileged access controls. Mandatory unless an authorized exception is granted.
  • Group B, preferred patterns: Terraform modules, KMS patterns, private network templates. Alternatives are fine if they meet the outcomes.
  • Group C, workload decisions: service split, authorization placement, application key boundaries, field-level encryption choices. The Solution Architect decides.

And build a paved road: account vending, infrastructure modules with logging and encryption built in, standard identity patterns, pipeline checks, and a time-limited exception route. Engineers take the easy road. That is being human, not lazy. Make the safe road the easy one.

Example B: a Payment Initiation API on AWS

Scenario: customers create payments, see their own history and check status through an API. It runs on a managed API entry point, application compute and a database. A compromise could mean unauthorized transfers, leaked data, disputes, regulators calling and lost trust.

Layer 1: conceptual and architectural

Start with the business attribute profile (an example, validated by the Product Owner and business continuity people):

  • Confidentiality: High. Stop one customer seeing another's data.
  • Integrity: Very high. Stop unauthorized creation, change, replay or execution.
  • Availability: High.
  • Accountability: Very high. Reliable records of who started, approved and changed what.
  • Recoverability: High.

Integrity and accountability rank above confidentiality. A privacy-only view would under-protect what matters most.

Architectural direction that follows: authorization and state rules live in the payment service, not the gateway; approval functions are separated from customer functions; high-value payments can require a second approval; key administration sits outside the application team's reach; every material action produces an application-level audit event.

For verification, a company might choose ASVS Level 2 as the starting target, with independent testing for the highest-impact actions, and Level 3 for specific components like the one that approves and executes payments. That is a suggested policy choice, not a universal ASVS mapping. I list no ASVS requirement numbers on purpose. Map to the exact requirements in your pinned version.

Layer 2: technical and implementation

The flow: customer or client, API entry point, payment service, then the payment database and downstream processor. Three boundaries matter:

  1. The client is not trusted. Amounts, beneficiaries, IDs and status values could all be attacker-controlled.
  2. The gateway cannot enforce every business rule. Whether this customer may read this payment is application knowledge.
  3. Downstream systems need their own identity limits.

A STRIDE walk-through, in short:

  • Spoofing: a stolen or fake token. Outcome: tokens checked for integrity, issuer, audience and expiry. Evidence: tests with bad tokens.
  • Tampering: the customer changes amount, beneficiary or status. Outcome: client input cannot override trusted state. Evidence: tampering and concurrency tests.
  • Repudiation: "I never made that payment." Outcome: protected, structured audit events. Evidence: lifecycle completeness tests.
  • Information disclosure: changing a payment ID shows another customer's record. Outcome: every object access is checked against the caller. Evidence: automated cross-customer tests. Also, an admin reading stored account data. Outcome: sensitive fields unreadable without key authorization. Evidence: a storage-level read returns ciphertext.
  • Denial of service: floods and heavy queries. Outcome: bounded usage. Evidence: rate-limit and load tests.
  • Elevation of privilege: a customer calls an approval function. Outcome: explicit function-level permission and separation of duties. Evidence: function-level tests.

STRIDE gives breadth, not everything. Also model replay and duplicate requests, race conditions, transaction ordering, fraud through normal features and a compromised third party.

Derived, developer-ready requirements

Each is an outcome with a way to verify it:

  • APP-01, Object-level authorization. Every read or change checks the caller's right for that exact payment and action, on the server. Verify: cross-customer and unauthorized-change tests in the pipeline.
  • APP-02, Transaction integrity. Creation and state changes follow real business rules. Duplicates and replays are handled safely, for example with idempotency keys. Verify: tampering, duplicate and concurrency tests.
  • APP-03, Authentication and token validation. Check integrity, issuer, audience and expiry; use approved TLS versions. Verify: bad-token tests and a TLS scan.
  • APP-04, Auditability. Material actions create events with actor, transaction reference, action, result and time. Records are protected, and secrets are never logged. Verify: a drill that rebuilds a payment story from the records alone.
  • APP-05, Sensitive data protection. Tier 4 fields stay unreadable to anyone with only storage-level access (see Part 2). Verify: ciphertext test and key-policy review.
  • APP-06, Resilience. Limits and safeguards fit the availability the business approved. Verify: rate-limit, load and recovery tests.
  • APP-07, Secure delivery. Every change passes the right ASVS checks, dependency checks and infrastructure checks. Verify: kept pipeline and exception records.

What the platform does not prove

The API gateway, WAF, storage encryption and central logging are useful, and mostly inherited. But none of them, alone or together, proves:

  • Application-level authorization. A WAF has no idea who owns payment 8841.
  • Transaction integrity. Encryption does not decide whether a status change is legal.
  • Complete business-event auditability. CloudTrail records AWS API activity, not "payment created, approved, rejected or amended."

That is why Example A is necessary but not enough. The platform baseline is inherited. The application requirements are designed.

One risk, traced end to end

  1. Business impact: unauthorized payments cause direct money loss and customer harm (owner: Product Owner, checked with Risk).
  2. Security objective: prevent unauthorized creation, change and execution of payments.
  3. Framework or policy: company access-control and app-verification policy; selected ASVS requirements at the chosen level.
  4. Threat scenario: Layer 1, one compromised service could approve and execute alone. Layer 2, tampering, privilege escalation and replay.
  5. Architecture decision: authorization and state rules in the payment service; approval functions separated; idempotency required. Recorded in a decision record.
  6. Implementation control: object and function authorization checks; a payment state machine that rejects illegal moves; idempotency keys; two-person approval for high-value payments, if the business wants it.
  7. Verification evidence: negative authorization and tampering tests in CI, replay tests, an audit completeness test, release gate results, an independent test report.
  8. Risk or exception decision: open findings above the threshold go to the authorized risk owner with a time-limited exception and backup controls. Not to the delivery team.

If any step is empty, you found the weak spot.

The enterprise dilemma: PMO vs. TOGAF ADM

Even with great requirements, one question remains: where do these activities live in the way the organization really builds things? Two frameworks usually compete for the answer.

  • The PMO delivery framework controls projects: timeline, budget, resources and stage gates. It asks, "Are we on time and on budget? Can we pass the next gate?" (PMOs run waterfall, hybrid and agile-at-scale; I mean the delivery governance layer in general.)
  • TOGAF ADM is a repeating cycle for designing architecture: Preliminary, then phases A to H, with Requirements Management at the center (TOGAF 10th Edition). It asks, "Is this the right design for the enterprise?"

One important fact: ADM is a process wrapper, not a security method. It has no control list. The security content comes from the four approaches. ADM and the PMO organize when and how that content gets used. And Requirements Management is continuous (ADM Requirements Management).

The trap of the PMO alone

  • Security becomes a checkbox. The gate asks "did you do the review?", not "is the design sound?"
  • Late-stage firefighting. The security gate sits near go-live, when the design is fixed and any real finding means rework.
  • No reuse. Every project re-solves identity, logging and encryption.
  • The budget wins. When security competes with scope and schedule, the cheapest answer wins. That is the disk-encryption checkbox again.

The trap of TOGAF ADM alone

  • The ivory tower. Beautiful target architectures nobody can fund or schedule.
  • No link to velocity and money. Without the PMO's gates and funding, architecture decisions are advice, not commitments.
  • Late feedback from reality. The design drifts from what actually gets built, and nobody notices until audit.

The answer: use both, on purpose

The PMO provides the timing and the gates. ADM provides the architectural rigor. The four approaches provide the content. The two-layer threat model provides the focus.

Here is how I would wire them together. This mapping is my suggested practice. It is not part of TOGAF or any PMO standard.

  • Before any project (ADM Preliminary): set principles, decision rights, a baseline control catalog, reference patterns and the exception process.
  • Concept (Phase A): business outcomes, criticality, regulation. The Product Owner signs off the tier.
  • Planning (Phases B and C): sensitive processes, data classification, data flows. Layer 1 threat model, then the first Layer 2 model. Choose the ASVS level by tier.
  • Design (Phases D and E): cloud patterns, trust boundaries, identity. Pick the "how" from approved patterns, like the encryption pattern for the tier.
  • Roadmap (Phase F): order fixes by risk and value.
  • Build and test (Phase G): verify that what was built meets the requirements, and manage deviations.
  • Go-live and operate (Phase H): reassess after changes, incidents and new threats, and refresh both threat-model layers.
  • Throughout (Requirements Management): keep a versioned catalog and traceability current.

Two big wins:

  • Security work moves left. The tier is signed at concept, and the threat models happen at planning and design. So go-live checks evidence instead of discovering surprises.
  • The gates get teeth. "Tier signed by the Product Owner, threat models reviewed, ASVS evidence attached, encryption pattern matched to the tier" is much harder to fake than "security review: complete."

Keep it agile

Run two speeds. Governance speed (slow): principles, baselines, patterns, decision rights. Delivery speed (fast): threat models, tests, designs, implementation choices.

  • Build the architecture runway of reusable platform patterns before teams need it.
  • Pull security requirements into backlog refinement from a catalog.
  • Do Layer 1 early and rarely, and Layer 2 when designs or trust boundaries change.
  • Let CI/CD check requirements all the time, so evidence is a side effect of delivery.
  • Write short decision records only when decisions affect risk or future change.

My test for "no bureaucracy": does an engineer in a normal sprint ever have to open an ADM document? If not, the wrapper works.

A word on regulation: if your organization is a financial entity in scope of the EU's Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554, applicable since 17 January 2025), its rules become more inputs for the governance approach. Whether it applies depends on your entity type, country and services. Nothing here is legal advice.

Four golden rules

Rule 1: Source from several approaches, and model threats at two layers. — Business tells you why and how much. Governance tells you what applies. Platform tells you what you inherit. Threat tells you what could break here.

Rule 2: Write threat-aware, tiered, provable requirements. — "Encrypt at rest" invites the cheapest answer. Tie each control to a tier and a threat. Write every baseline control as What, allowed How, and Evidence.

Rule 3: InfoSec owns the "what," architects own the "how," the business owns criticality. — Keep policy exceptions and risk acceptance as separate decisions with separate owners, both with end dates.

Rule 4: The PMO owns the clock, ADM owns the design. Use both. — Keep a versioned, machine-readable requirements catalog so engineers meet requirements in the pipeline, not in a document.

None of this is another checklist. A requirements system lets you answer five questions about every important requirement:

  1. Why does it exist?
  2. Who is accountable?
  3. What must the architecture guarantee?
  4. How will the build prove it?
  5. What happens if we cannot meet it?

When you can answer those, the friction between security, architecture and delivery stops being a fight about opinions. It becomes a conversation about evidence.

Your turn: Does your encryption-at-rest requirement distinguish storage-level from application-level protection? Who owns the clock in your organization, the PMO or architecture? And who really signs off on asset criticality: the business, security, or nobody? Tell me in the comments.

Series: Part 3 of 3. Add links to Parts 1 and 2 here when published.

Sources for Part 3