House of Data Series

Every strong data program is built like a house. Data Architecture forms the foundation — the platforms, pipelines, and operating model that everything else depends on. Seven domain pillars rise from that foundation, each one essential to a complete data program: Data Quality, Privacy, Data Security, DataOps, Compliance, Data Enablement, and Data Consumption. Data Literacy runs across all seven as a connecting beam, ensuring people at every level can read, interpret, and act on data. At the top, People & Leadership sets the direction, accountability, and culture that holds the whole structure together.

This series of whitepapers covers each component of the House of Data in depth. Each paper was written by a practitioner with direct experience in that domain. Together, they form a practical guide to building data programs that earn — and keep — trust.

This paper covers Data Security — the operational discipline that enforces how data is protected, controlling access, verifying identity, and tracking activity across the organization.

Data security

Data Security is the third pillar of the House of Data. It provides the "how" of data protection — while data governance defines what data exists and who should access it, security enforces those decisions. The CIA triad (Confidentiality, Integrity, Availability) and AAA framework (Authentication, Authorization, Accounting) are its operational backbone. Security and governance aren't competing functions; in mature organizations, they're tightly coordinated.

Introduction

Data governance and data security get conflated all the time, which is understandable. They overlap, they share language, and in many orgs, they're tangled up in the same tools and processes. But let's be clear: data security is a critical function within a broader governance strategy, not a replacement for it.

In a mature organization, you'll see distinct policies, accountabilities, and workflows for each. And yet, the two must be tightly aligned because protecting your data without governing it is reactive, and governing data without securing it is naive.

While data governance defines the 'what' and 'why' of data management, data security provides the 'how' of protection. This paper is about bridging that gap: how security fits into governance, why the relationship matters, and what every data stakeholder from stewards to CISOs needs to understand to get it right.

Successful data programs focus on two things: Alignment and Momentum. Many firms try to have a silo for data security, another silo for data governance (including stewardship), and a third for governance, risk, and compliance (GRC). These groups then compete with each other, and do not work well together. As you review what data security needs, think about how you can get alignment across these groups, increase collaboration, and work together to address this very difficult challenge of data security.

Data security vs. data governance

The roots of modern data security and information security more broadly trace back to two places: the military and financial sectors.

In the military world, confidentiality is everything. If a document is classified as top secret, it must stay that way. In fact, in extreme cases, a military mindset would rather destroy the data entirely than risk it falling into the wrong hands. That's confidentiality taken to its logical end: better no data than leaked data.

Now contrast that with banking. Here, integrity is king. If you make a deposit and then a series of withdrawals, the math needs to add up. Every transaction must be recorded faithfully, and the final balance should be correct down to the cent. Of course, you don't want just anyone seeing your balance but more critically, you don't want that number changing arbitrarily. That's what integrity protects.

So: confidentiality is about keeping secrets. Integrity is about keeping truth. And both are essential. But neither matters if your data isn't available when you need it. That's the third leg of the classic security stool: availability. Without backups, redundancy, and resilient infrastructure, even perfectly protected data can become useless.

Confidentiality, integrity, and availability — the CIA triad — are foundational to both security and governance. But how those priorities show up can vary wildly depending on the context. And understanding that nuance is where real alignment begins.

Data security methods: AAA

If the CIA triad defines what we're trying to protect, how do we operationalize it day-to-day? That's where AAA — Authentication, Authorization, and Accounting — comes in.

In data security, the CIA triad is the foundation of any sound security model. But if CIA defines what we're trying to protect, then AAA defines a big part of the how. These are the control mechanisms that security teams use every day to enforce policy, manage risk, and keep systems honest.

Authentication answers the first and most basic question: Who are you? Whether it's a user logging into a dashboard, a service calling an API, or a device requesting a certificate, authentication is about verifying identity. Without reliable authentication, confidentiality collapses because you don't know who's accessing your data in the first place. Strong auth mechanisms like MFA, identity federation, and certificate-based auth are the front door to every secure system.

Once identity is established, Authorization steps in: What are you allowed to do? This is where RBAC, ABAC, and fine-grained permissions come into play. Authorization enforces both confidentiality (who can see what) and integrity (who can change what).

Finally, Accounting — sometimes called audit or activity logging — closes the loop. It tracks who did what, when, and where, creating the forensic and compliance backbone that supports integrity and availability. If authentication is the front door and authorization is the keys to the rooms, accounting is the security camera that records every move.

Armed with these three concepts, security teams are able to build and maintain tools and processes which support the Confidentiality, Integrity, and Availability of corporate data.

Relating CIA to AAA

Data security teams

The job of ensuring CIA from a Data Security perspective often includes teams with these key roles. These are your key partners in the Data Security realm.

• CISO — The CISO sets the strategic direction for protecting data and systems. They translate risk into action balancing business priorities with real-world threats. At their best, they're not just enforcing policy; they're enabling secure growth.
• Security analyst — Analysts live in telemetry. They investigate alerts, detect patterns, and surface anomalies before they become incidents. Their work is the front line where data turns into insight and response begins.
• Security engineer — Engineers build the controls that protect your environment — everything from IAM policy to encryption pipelines. They turn security principles into running code and enforceable boundaries. A good one quietly prevents dozens of issues you'll never hear about.
• Security architect — Architects see the big picture. They design systems that are secure by default, ensuring security scales with the business. If the engineer is building the walls, the architect decides where to place the doors and what locks to use.
• Security auditor — Auditors verify whether what's supposed to be happening is actually happening. They test controls, inspect documentation, and map reality to policy and regulation. Their work isn't glamorous but it's essential for trust and accountability.
• Forensic expert (DFIR) — When things go wrong, the forensic expert (often a Digital Forensics and Incident Response engineer) digs into the timeline. They recover deleted files, trace lateral movement, and reconstruct what really happened. Think of them as incident archeologists — part detective, part surgeon.
• Data steward — Data stewards are the unsung heroes of governance. They ensure data is accurate, well-documented, and responsibly shared across the org. Increasingly, they're stepping into the security conversation because you can't protect what you don't understand.

Understanding data security risk

Data security risk is the potential for sensitive or critical data to be exposed, altered, destroyed, or made unavailable — either maliciously or accidentally — in ways that impact the business. That might mean leaked customer PII, corrupted financial data, ransomware-induced downtime, or even subtle privilege creep that goes unnoticed until it's too late.

Most organizations use a basic 5x5 risk matrix to score and prioritize these risks. You assess each risk by estimating likelihood (how probable it is) and impact (how bad it would be if it happened), each on a 1–5 scale. The result helps prioritize controls, budget, and executive focus. It's not perfect but it gives teams a shared language for assessing where the real threats live.

Common external risks

• Ransomware targeting production data and backups — A single compromised credential or unpatched system can result in widespread data encryption, data loss, and service downtime. The impact here isn't just technical — it's financial and reputational.
• Cloud misconfiguration exposing data to the public internet — Open S3 buckets, overly permissive IAM roles, or misconfigured access policies are one of the top root causes for external data leaks.
• Supply chain compromise via third-party vendors — Partners and platforms with access to your systems or data can become indirect attack vectors. If you don't track what they can access, you can't protect it.

Common internal risks

• Privilege sprawl and excessive access — Over time, users collect permissions they no longer need. Without regular reviews and revocations, this creates unnecessary blast radius and increases the risk of insider misuse — intentional or accidental.
• PII or secrets leaking into log data — Debug logs, observability tools, and analytics pipelines often get overlooked during DLP reviews. Entire API keys and credit card numbers have been accidentally logged into unsecured indexes.
• Shadow IT and unsanctioned data flows — When teams spin up their own tools or bypass governance, data ends up in uncontrolled systems with no security visibility. This undermines both confidentiality and compliance.

Every one of these risks is preventable. But only if they're visible, documented, and prioritized. That's where the risk register comes in — it's your shared contract across Security, Governance, and the business. If it's not in the register, it's not getting fixed.

The role of the risk register

The risk register isn't just a spreadsheet full of scary possibilities — it's the connective tissue between governance, security, and executive accountability. It's where theory becomes plan. And in a well-run organization, it's a living document: reviewed, updated, and actioned as part of an ongoing governance and risk process.

Each entry in the register typically includes:

• A clear risk statement (e.g., "Customer PII may be exposed via misconfigured cloud storage").
• A likelihood score and impact score, often using a 5x5 matrix to calculate inherent risk (i.e., the raw risk before any controls are applied).
• Existing controls that help mitigate the risk (e.g., access policies, encryption, logging).
• A proposed or in-progress remediation plan — what needs to be done, by whom, and by when.

Once those controls are applied, the team evaluates an adjusted risk score — also called treated risk — to reflect the risk as it stands with current safeguards in place. This lets leaders see where remaining risk still exceeds appetite, where plans are working, and where additional action is needed.

And sometimes, the answer isn't more remediation — it's risk acceptance. Maybe the cost to fix a low-likelihood issue outweighs the business value. Maybe compensating controls are in place elsewhere. In those cases, formal acceptance with executive acknowledgment is critical. Sweeping unremediated risks under the rug is a recipe for surprise incidents and audit findings.

In short: the risk register is your cross-functional contract. Security surfaces the issue, governance ensures it's documented and tracked, and the business decides how to act. That shared accountability is the difference between organizations that merely observe risk and those that actually manage it.

For more information on Data Security Risk Registers check out: ISO 27001 - Data Security Risk Register

Data security policies and standards

Security frameworks like SOC 2 Type 2 and ISO 27001 aren't just audit checklists — they're playbooks for what good security looks like at scale. They define expectations for how data should be protected, how risk should be managed, and how organizations should hold themselves accountable. And while the security team may lead the charge, data governance teams are key players in turning those expectations into reality.

Standards drive policy

Standards like SOC 2 and ISO 27001 serve as structural backbones for internal security policy. They don't dictate every line of your documentation but they do require you to have clear, enforceable policies across a range of areas, including:

• Access control
• Data classification
• Encryption and key management
• Vendor risk
• Logging and monitoring
• Incident response
• Change management
• Data retention and disposal

These policies are the formal commitments an organization makes to itself, its customers, and its regulators. If you're pursuing ISO or SOC certification, auditors will ask: Do you have these policies? Are they current? Are they being followed? And most importantly: Can you prove it?

Policy informs implementation

Security policies, once aligned with the standard, need to cascade into standards and controls that engineers, analysts, and governance professionals can actually follow. A well-formed policy answers:

• What is required?
• Why does it matter?
• Who is responsible?
• How will compliance be verified?

From there, technical teams implement the controls, and governance teams map the data — identifying ownership, lifecycle, sensitivity, and access levels. This is where governance has leverage. Policies don't mean much if no one knows which datasets are subject to them. Data governance enables security enforcement by providing the metadata, classification, lineage, and stewardship necessary to enforce policy with precision.

The governance perspective

From a governance lens, your job isn't just to manage data — it's to make policy enforceable and auditable at the data level:

• If a security policy says "All PII must be encrypted," governance helps identify what's PII and where it lives.
• If SOC 2 requires role-based access control, governance ensures roles are defined, mapped to users, and reviewed regularly.
• If ISO requires that data be retained or deleted according to policy, governance defines the lifecycle and ensures it's followed.

In short, governance makes the abstract concrete. It turns policies into tagged records, classified tables, ownership charts, and access boundaries. Without that visibility and structure, security policy becomes aspirational and compliance becomes a guessing game.

Data security's role in AI trust

AI systems are only as trustworthy as the data they're built on. That means the security and governance teams aren't just protecting systems anymore — they're protecting training sets, inference pipelines, and ultimately the model outputs too. If you want trusted AI, you need trusted data. And trusted data starts with CIA.

Security and governance teams' role in AI governance touches every phase of the lifecycle.

Secure inputs = secure models

Before a model is even trained, these teams should be asking:

• Where is this data coming from?
• Does it contain PII or regulated content?
• Can it be validated or fingerprinted?

If the model is learning from poisoned data — whether by accident or adversary — it will encode that untrustworthiness into every prediction. And once it's in the weights, it's nearly impossible to unwind.

Enforcing confidentiality and usage controls

AI models often consume logs, chat transcripts, documents, or customer data — some of which were never meant to be reused outside their original context. Without proper data classification, masking, and access control, sensitive data can be silently ingested and repurposed in ways that violate trust, regulation, or internal policy. Security ensures that only the right data is used in the right way — and that model training doesn't become a compliance risk vector.

Guardrails during inference

Just because a model is deployed doesn't mean the risk ends. At inference time, models can leak training data, hallucinate sensitive information, or generate toxic or biased outputs based on flawed inputs. Security teams play a key role in:

• Monitoring inference logs
• Applying output filtering or post-processing
• Detecting abuse patterns or prompt injection

This is especially true in customer-facing generative AI applications, where one poorly constructed answer can turn into a brand or legal crisis.

Auditing, lineage, and attestation

Just like any regulated process, AI decisions need to be traceable. Security can help enforce lineage tracking:

• Where did the data come from?
• Who modified it?
• What version of the model used it?
• Was the model finetuned? By whom?

This level of auditability and attestation isn't just a security concern — it's a cornerstone of building trust with users, regulators, and internal stakeholders alike. No AI is trustworthy by default. It has to be made trustworthy through good data, good controls, and good governance. And that starts with security at the table from day one.

ISO certifications

ISO 8001 — This standard addresses underexposed motion-picture film processes. It provides definitions and recommendations for processing and evaluating film quality within the cinema industry.

ISO 9001 — The most universally recognized quality management standard, ISO 9001 specifies requirements for a quality management system (QMS) and helps organizations of any size ensure consistent product/service quality, compliance, and customer satisfaction. It's used globally to support continual improvement and operational excellence.

ISO 32001 — This is a technical specification for Portable Document Format (PDF 2.0), introducing support for modern hash algorithms (such as SHA-3) to strengthen digital signature capabilities and document authentication.

ISO 32002 — Another PDF 2.0 extension, this specification focuses on enabling new digital signature algorithms (including NIST P-curve, Brainpool, and EdDSA Ed448/Ed25519 elliptic curve cryptography), ensuring advanced cryptographic security for digital documents.

Bigeye's role in data security

Bigeye offers a range of capabilities for data including data quality checks, lineage, and issue resolution. There are teams of professionals that focus on data security and need help in meeting their needs. This includes data governance and governance, risk, and compliance (GRC). These groups use the Bigeye platform more extensively.

There is a key area of Bigeye that data security professionals gain great benefits from: lineage. Lineage graphs, particularly impact analysis, provide data security professionals the benefit of reviewing a data object and seeing all the places that it is used. The data security professional can see the downstream impact of changes they are proposing and can use that information to assist in their communication of a change or in developing solutions that are in line with business risks and impacts.

Further, the privacy challenges that data security professionals need to contend with are better managed with sensitive data scanning. The ability that Bigeye provides to scan data in a system and identify where data lives that has exposure related to privacy regulation is critical to data security professionals.

Here are two examples of capabilities that Bigeye provides: the first is a lineage graph that can be used to show impact analysis of a security change. If we close off access to a table, what reports will be impacted.

This illustrates sensitive data scanning — it empowers the data security analyst to see data objects that may need to have rights reviewed for appropriateness, after a scan is run.

Summary

In conclusion, data security is an area that requires collaboration, communication, and respect of the need. When working in providing access, reviewing access, producing or running your data governance — give the time to data security to be successful. There is a wide range of responsibilities that the data security professionals must complete; it is vital that data governance, data security, and GRC are working together to drive those forward.

References

AuditBoard. (2025, April 1). NIST vs. ISO: What’s the difference? https://auditboard.com/blog/nist-vs-iso-whats-the-difference

BEMO. (2024, February 1). What is the CIA triad? https://www.bemopro.com/cybersecurity-blog/what-is-the-cia-triad

Cegal. (n.d.). The CIA triad. https://www.cegal.com/en/dictionary/cia-triaden

EBSCO. (2025, March 3). Confidentiality, integrity and availability (CIA triad). https://www.ebsco.com/research-starters/information-technology/confidentiality-integrity-and-availability-cia-triad

Isora GRC. (2025, June 22). Conducting a NIST 800-53 risk assessment. https://www.saltycloud.com/blog/nist-800-53-risk-assessment-guide/

National Institute of Standards and Technology (NIST). (2020). Executive summary: NIST SP 1800-26 documentation. https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html

NIST Computer Security Resource Center (CSRC). (2022, September 26). Risk management. https://csrc.nist.gov/nist-cyber-history/risk-management/chapter

NVIDIA. (2025, February 12). Authentication, authorization and accounting (AAA). https://docs.nvidia.com/networking/display/ufmenterpriseapplianceswv1110/Authentication,+Authorization+and+Accounting+-+AAA

SailPoint. (2025, January 16). CIA triad: Confidentiality, integrity, and availability. https://www.sailpoint.com/identity-library/cia-triad

Secureframe. (2021, February 24). How to conduct a risk assessment for NIST 800-53 compliance + examples. https://secureframe.com/hub/nist-800-53/risk-assessment

StrongDM. (2025, June 25). What is AAA security? Authentication, authorization, and accounting. https://www.strongdm.com/blog/aaa-security

TechTarget. (2024, October 28). What is authentication, authorization and accounting (AAA)? https://www.techtarget.com/searchsecurity/definition/authentication-authorization-and-accounting

UNISENSE Advisory. (2025, June 10). Understanding ISO 27001 CIA triad principles. https://unisenseadvisory.com/iso-27001-cia-triad-principles/