A Security Framework for Applications and Data Platforms: Foundation, Domains, Lenses

TL;DR

Security for an application or a data platform sorts into one foundation (governance and risk), eleven domains grouped by the question each answers, and a few lenses (compliance, AI, shared responsibility, workload type) that apply to every domain. Categories give each safeguard one home and one owner; without them, a safeguard comes up in three meetings and belongs to nobody.

• The foundation decides what matters, who owns it, and how much risk is acceptable.
• The domains do the work: identity, data, systems, operations, and suppliers.
• The lenses re-read the domains. A regulation, an AI feature, or a cloud move adds no domain; it changes what each one covers.

Why categories matter

Security on a project usually starts as a list: governance, identity, data access, data protection, DLP and privacy, application security, network, data governance, monitoring, secure development, compliance, AI, third parties. A list is a fine start and a poor finish. Items overlap (data protection, privacy, and compliance all claim encryption), leave gaps (nobody is asked who restores data after ransomware), and lack owners ("AI security" gets discussed and never done).

A useful category passes three tests: it answers one question, it has a natural owner, and its evidence looks alike (a configuration, a test result, a contract). Sorting the list by those tests produces three different kinds of category.

The model at a glance

Think of a building: governance is the foundation that carries everything, the domains are rooms with a purpose and someone responsible, and the lenses are inspectors (fire, accessibility, electrical) who own no room but walk through all of them.

The foundation: governance and risk

NIST's Cybersecurity Framework (CSF) 2.0 puts its Govern function "in the center of the wheel" because it informs every other function. It holds five things:

• Risk appetite: how much risk the business accepts, written down.
• Owners: a named person for every system and every important dataset.
• Inventory: systems, data stores, software accounts, and suppliers.
• Policy and exceptions: the rules, plus a dated register of approved deviations.
• Risk tiers: how sensitive the data is and how exposed the system is. A public-facing platform holding customer data gets a deeper review than an internal dashboard.

It comes first because every domain refers back to it. "Encrypt sensitive data" means nothing until someone has decided what counts as sensitive and who signs off on exceptions.

Eleven domains, grouped by the question they answer

The "what good looks like" column doubles as a starting checklist.

Identity: who is acting?

Identity gets its own group because every other domain assumes you know who is asking. On a data platform much of the traffic comes from software (pipelines, report refreshes), and when a report server queries data under one shared account, the logs show the account and per-person rules cannot apply.

Data: what are we protecting, and on what terms?

Four domains, because each has a different owner: data engineers run access rules, the platform team runs encryption and keys, privacy and legal decide what use is allowed, and data owners make governance calls. Rule of thumb: governance decides (label, owner, retention), protection enforces (the encryption, masking, or deletion that runs). DLP watches the exits, so it sits with protection; privacy asks whether the use is allowed at all,, a risk NIST calls "closely related" to cybersecurity yet distinct enough to need its own owner.

Systems: what are we building, and what does it run on?

Think of these as the product, the factory, and the floor. On a data platform the "software" includes notebooks, transformation code, and report definitions, and they belong in the same factory controls as application code.

Operations: how do we notice, respond, and recover?

Detection and recovery have different owners and different tests, which is also why "secure development, deployment, and resilience" splits: build pipelines and restore tests share neither.

Ecosystem: who else is involved?

CSF 2.0 gives supplier risk ten outcomes, from ranking suppliers by criticality to what happens "after the conclusion of a partnership". It earns its own group: Verizon's 2026 breach report found a third party involved in 48% of breaches.

Common lenses

A lens is a question asked of every domain. It adds requirements, never a new home for safeguards.

Compliance: which rules apply?

A regulation is met by safeguards that already live in the domains. Keep the list of obligations in the foundation and tag each safeguard with the rules it satisfies ("implement once and comply everywhere"). The list moves: the EU AI Act's high-risk obligations now apply from December 2027 and August 2028, and the tags move with it.

AI: what changes when the system retrieves, generates, or acts?

Mostly, AI adds new assets to existing domains. The Cloud Security Alliance's AI Controls Matrix has 247 control objectives; only the 13 in Model Security have no counterpart in the cloud catalog it extends. OWASP's fix for AI assistants that leak documents is "permission-aware vector and embedding stores", which is data access control under another name.

Shared responsibility: who runs each control?

When you rent infrastructure, a platform, or finished software (IaaS, PaaS, SaaS), the provider takes over more of the domains as you move up that ladder. Some never move. As one major provider puts it, "for all cloud deployment types, you own your data and identities". In the 2024 attacks on Snowflake customers, Mandiant found no evidence of a breach of the provider's own environment and traced the incidents to stolen customer credentials on accounts without MFA. Mark each domain provider, customer, or shared, and review the customer side hardest.

Workload type: application or data platform?

Same eleven domains, different weight.

On a data platform, an access rule set in one tool does nothing for another tool reading the same files, so test it through every path. Copies open an exit route: IBM found that more than a third of 2024 breaches involved "shadow data", data outside IT's control.

Common misunderstandings

"We passed the audit, so we are secure." An audit confirms that safeguards exist. NIST's assessment guide asks whether they are "implemented correctly, operating as intended, and producing the desired outcome". Verizon found organizations fully fixed only 26% of critical known-exploited vulnerabilities, a gap a documented patch process hides.

"The data is encrypted, so it is safe." Encryption at rest protects against stolen disks and direct access to storage. Anyone who signs in with valid credentials reads the data decrypted, which is why stolen credentials were enough in the Snowflake attacks.

"Hashed data is anonymous." Under GDPR Recital 26, data that can be linked back to a person with additional information is still personal data. A hashed customer ID stays personal while the lookup table exists.

"MFA covers our identities." MFA protects people. Pipelines, scheduled jobs, and AI agents sign in with keys and secrets, and OWASP lists long-lived secrets among the top risks for these non-human identities. They need an owner, an inventory entry, and a rotation date.

"We have backups, so we can recover." A backup that has never been restored is a hope. CISA's ransomware guide asks for "offline, encrypted backups" and regular tests of their availability and integrity, kept out of reach of an attacker with admin rights.

Putting it to work

1. Start with the foundation: an owner, an inventory, and a risk tier.
2. Walk the eleven domains and keep the "what good looks like" rows that apply.
3. Apply the lenses that fit: regulations, AI features, hosting model, workload type.
4. Ask for evidence over answers. A configuration screenshot or a tested restore says more than a "yes".
5. Map to a standard when an auditor asks. CSF 2.0 is a good hub because it "does not prescribe how outcomes should be achieved", and ISO/IEC 27001, the CIS Controls, and sector rules map onto it.