Security Requirements That Actually Work — Part 2: Who Owns the “What,” the “How,” and the Risk?

InfoSec, architects and Product Owners keep fighting over security requirements. Here is a clear ownership model, and the encryption example that shows why it matters.

In Part 1, I argued that good security requirements come from four approaches (business, governance, platform and threat), and that threat modeling works best in two layers.

Now the harder question: who decides what?

Here is a scene you may know. InfoSec writes, "Use AWS KMS with customer-managed keys." The architect says the platform already uses another key service. InfoSec says, "That's our standard." The architect says, "That's a design choice." Nobody wins, and the project slips.

And then there is the quieter failure. A team ticks the "encrypt at rest" box, passes the audit, and is still exposed to the threat the requirement was written for.

In this part:

• Who owns the what, the how, and criticality.
• A RACI that separates risk acceptance from policy exceptions.
• The encryption paradox, and how data tiers fix it.

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. Tiers, ratings and the RACI are examples.

The core boundary, refined

"InfoSec owns what, architects own how" is a good slogan, but a bit too simple. Here is my more careful version:

Security governance defines the required outcomes and the rules that cannot be broken. Architecture chooses the right design inside those rules. Engineering builds it. Assurance checks it. And the business decides how much the asset matters.

Three levels of detail

Most bad requirements are written at the wrong level.

• Security outcome (what must be true?): sensitive customer data must be protected from unauthorized reading and changes.
• Architecture requirement (what must the design provide?): only approved people and workloads can reach the data service, and access must be traceable and logged.
• Implementation decision (how do we do it?): private connections, workload-specific IAM roles, application-level checks, encryption, automatic audit evidence.

InfoSec mostly owns the first, shares the second, and the Solution Architect owns the third.

InfoSec owns the "what"

A good InfoSec requirement describes a result you can check.

• Weak: "Use AWS KMS for all encryption." (Met the moment KMS exists, which proves little.)
• Better: "Sensitive data must be encrypted at rest and in transit with approved methods. Key access, rotation, separation of duties and recovery must match the data tier."

The same goes for identity ("each production workload must have its own identity with only the permissions it needs") and APIs. Authentication tells you who is calling. It does not tell you whether they are allowed to touch this object. So write it down: the server must check authorization using the caller, the action, the object, the tenant and the business context. An API gateway or web application firewall (WAF) cannot know that payment 8841 belongs to Customer A.

Architects own the "how"

The architect decides whether the result comes from AWS KMS, Azure Key Vault or HashiCorp Vault, based on what InfoSec cannot see: the existing platform, performance, team skills, the multi-cloud plan, cost and lock-in.

If InfoSec picks the product:

• Architects cannot choose what is best for the whole system.
• InfoSec quietly owns a design it did not build.
• When it fails, InfoSec shares the blame and the extra work.

Platform benchmarks are the most tempting thing to hand to InfoSec, because they make neat checklists. Resist. Platform settings are design decisions, and whoever writes them also inherits patching, key rotation and keeping the security service running.

One caveat: enterprise policy can legitimately mandate shared services, like one identity provider or one logging pipeline. That is a fair "how" rule when someone owns it and there is a reason.

The business owns asset criticality

Someone has to decide how critical each asset is. It should be the Product Owner or business owner, because the impact lands on their P&L: lost revenue, fines, downtime, unhappy customers, damaged brand.

• If InfoSec picks the tier, the business says, "Security made it Tier 3, that's why we're over budget."
• If Engineering picks it, they may choose lower to ship faster.
• Only the business owner has both the context and the stake. InfoSec challenges and advises.

"How critical is it?" is really four questions:

1. Business impact: what damage would follow? (Product Owner)
2. Data classification: what privacy, integrity and retention rules apply? (Data owner, with privacy and compliance)
3. Technical risk: how likely is a break-in? (Security and architecture)
4. Residual-risk acceptance: who may accept what remains? (Someone with written authority)

The enterprise RACI (an example)

No single RACI fits every organization. Your delegated authorities decide the real answers. (R = Responsible, A = Accountable, C = Consulted, I = Informed.)

• Business or Product Owner: A for business impact and criticality, for choosing the workload security profile, and for reassessing after major changes. Usually A for data classification and for accepting material business risk (depends on delegated authority).
• InfoSec and Security Architecture: A for security policy and minimum outcomes. R for Layer 1 and Layer 2 threat modeling support. C on most other items.
• Solution Architect: A for technical design and for threat modeling.
• Engineering and Platform: A for implementing controls. R for supporting design, verification and reassessment.
• Risk and Compliance: A for independent verification of controls. A for policy exceptions (often with the policy owner). C/R on risk acceptance.

Four things to notice:

• Business impact is not risk acceptance. The Product Owner describes consequences. Whoever has written authority decides whether leftover risk is okay. That might be the business owner up to a limit, and a risk committee above it.
• A policy exception is not risk acceptance. An exception breaks a policy, and the policy owner approves it. Risk acceptance is about leftover risk. One deviation can need both decisions, from two different people.
• The Product Owner cannot downgrade risk to skip controls, and InfoSec should not invent business-impact ratings.
• Verification needs distance. The builder of a control should not be the only one who says it works.

My rule of thumb: business owners own business consequences. Security teams own policy and technical risk advice. Architects own design. Authorized risk owners own leftover risk.

The encryption paradox

Back to "Encrypt data at rest." There are two very different ways to meet it.

• Storage-level encryption. The platform encrypts the disk or storage. On AWS: encrypted EBS volumes, or S3 server-side encryption with S3-managed keys (SSE-S3). It is a checkbox, transparent to the app, and a sensible baseline.
• File-level or application-level encryption. The application encrypts data before storing it, often with envelope encryption (a data key encrypts the data, a master key in a service like AWS KMS encrypts the data key). A common version is field-level protection: only sensitive fields, like an account number, are encrypted.

The question that matters: who can still read the data in plain text?

• Stolen disk or decommissioned drive: both options protect you.
• Snapshot or backup copied without key access: storage-level generally protects you (depends on key permissions). Application-level does too.
• Attacker gets into the application or host OS: storage-level does not protect you, because the storage layer decrypts transparently for the app. Application-level helps, because fields stay encrypted unless the attacker can also use the key.
• Valid storage credentials, like an over-broad S3 read permission: storage-level does not protect you. An authorized read returns plain text. Application-level protects you if they lack the key.
• A database or cloud administrator browsing data: storage-level does not protect you in most designs. Application-level does, if key access is separated from data administration.
• SQL injection or an app bug leaking records: storage-level does not protect you. Application-level depends on whether the leaked fields are ever decrypted in that code path.

(Details vary by service and configuration. For example, AWS now applies SSE-S3 by default to new S3 objects, but a principal allowed to read the object still gets plain text. Check current behavior for each service you use.)

Here is the paradox: storage-level encryption passes the audit checkbox and still fails against application-layer compromise and insider threats. It was built for a different threat: lost or stolen media. That is a real threat, and it handles it well. But if your worry is a compromised app or a curious administrator, the checkbox gives you a feeling of safety and very little protection.

File-level encryption is not free:

• Searching and sorting encrypted fields is harder.
• Performance and complexity go up.
• Key management becomes the real security problem. If the app has broad key access, you only moved the weak spot.
• It needs application changes. It is a design decision, not a toggle.

So the answer is not "always use field-level encryption." It is: tie the requirement to the threat and to the sensitivity tier.

Tier the requirement

Separate data sensitivity (how bad is a leak?) from service criticality (how bad is wrong data or downtime?). A payment API may hold normally classified data but need very high integrity and availability. Don't squash everything into one score.

This four-tier model is an example of company policy, not an official NIST, ISO or OWASP scheme:

• Tier 1, Public: confidentiality encryption not required; protect integrity.
• Tier 2, Internal: storage-level encryption with managed keys.
• Tier 3, Confidential: storage-level encryption with customer-managed keys, plus application-level protection for specified sensitive fields.
• Tier 4, Restricted or Critical: application- or field-level envelope encryption with central key management, with key administration separated from data administration.

Now the requirement names the threat. A Tier 4 team cannot pass with a disk checkbox. And it still names no product, so the architect chooses how.

Here is the Tier 4 requirement written properly:

• What: Tier 4 data must remain unreadable to a party with access to the storage layer, database or host who lacks authorization to use the encryption key. Key administration must be separated from data administration.
• Allowed how (examples): envelope encryption with a central key service; field-level encryption in the application; enterprise-approved client-side encryption libraries.
• Evidence: a test showing a database-level or storage-level read returns ciphertext for protected fields; a key-policy review of who can use and who can administer keys; audit logs for key use.

This requirement is threat-aware, tiered, technology-neutral and provable.

Where ASVS fits

OWASP ASVS gives you testable application requirements in three levels. ASVS 5.0.0 came out in 2025 (around the end of May); pin the version you adopt, because IDs and levels changed. An example policy:

• Standard apps: selected ASVS requirements that apply, with written reasons for exclusions.
• Higher-risk apps: ASVS Level 2 as the starting target.
• Critical apps: Level 2 or 3, plus independent testing.

This tier-to-level mapping is a company policy choice. ASVS does not require it. ASVS does not classify your apps, and it is not a full risk model.

Part 2 takeaways

• InfoSec owns the what, architects own the how, the business owns criticality. Enterprise policy can mandate shared services, but it should say so on purpose.
• Separate business impact, data classification, technical risk and risk acceptance. And separate policy exceptions from risk acceptance.
• Storage-level encryption handles lost media. Application-level encryption handles compromised apps and insiders, at a cost.
• Tie requirements to a data tier and a threat, so the easy road is also the safe road.

Next in the series, Part 3: From Requirements to Release: AWS Baselines and the PMO-Meets-ADM Engine. An AWS platform baseline, a payment API example, and how the PMO and TOGAF ADM work together instead of fighting.

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

Sources for Part 2

• OWASP, ASVS and downloads
• AWS, Well-Architected Security Pillar. Check current AWS documentation for EBS and S3 encryption behavior.