Data Security Compliance: Translating Requirements to Controls and Evidence

A compliance requirement rarely tells a security team exactly what to configure. GDPR, for example, calls for “appropriate technical and organizational measures,” while NIST CSF organizes security around outcomes and functions. Organizations are left with the responsibility of translating the language of compliance into data security operating controls.

To make that translation concrete, follow the chain from requirement to policy to control to evidence: a regulation or standard creates the obligation, internal policy sets the organization’s rule for meeting it, controls enforce the rule, and operational records show whether those controls are working.

Data security compliance involves aligning organizational practices with established benchmarks and legal mandates to shield critical data assets from breaches and cyber threats.

Each type of requirement carries a different kind of obligation, with different expectations for implementation and proof.

• Laws and regulations create legal obligations. GDPR, HIPAA, NIS2 and the Digital Operational Resilience Act (DORA), for example, establish requirements for organizations or activities within their respective scopes.
• Security standards and frameworks describe controls, practices or outcomes. The Payment Card Industry Data Security Standard (PCI DSS) prescribes safeguards for payment account data, while the NIST Cybersecurity Framework provides a broader structure for managing cybersecurity risk.
• Certifications and attestations provide independent assurance against specified criteria or standards. An ISO/IEC 27001 certificate and a SOC 2 examination report fit into this category.

Internal policy sits between those external obligations and the controls used to satisfy them. A retention requirement, for instance, might lead to a data retention policy that defines how long certain records are kept, while lifecycle controls enforce the rule, and configuration history and deletion records provide evidence of implementation.

Watch how Snowflake Horizon Catalog uses classification, tags and masking policies to govern sensitive data within Snowflake:

Which requirements apply depends on the organization’s industry, geography, data and contractual relationships. A financial institution operating in Europe, for example, will face a different combination than a healthcare organization processing protected health information in the United States, even though both may rely on many of the same underlying security controls.

Compliance requirements often overlap even when they come from different regulators. In a 2026 review, the U.S. Government Accountability Office found that about 70% of the federal cybersecurity regulations it examined had the same type of reporting requirement as at least one other regulation.

Identity and access management, encryption, logging, vulnerability management, incident response, data classification and retention all address multiple obligations. Mapping requirements to a shared set of controls reduces duplicate work and gives compliance teams a clearer view of where evidence exists.

Using a service provider with security certifications and attestations gives an organization evidence for the provider’s portion of the environment — but the customer has its own responsibilities.

For cloud and software services, Inherit, Configure and Prove is a common conceptual model.

• Inherit: Customers rely on provider-operated controls within the provider’s scope, such as physical security, infrastructure protections and certain platform-level safeguards. Audit reports, certifications and responsibility matrices document those controls.
• Configure: Within their own environment, customers manage responsibilities such as identities, privileges, security policies, classification rules, network restrictions and workload configuration. The exact boundary varies by service, configuration and compliance requirement.
• Prove: During an audit or assessment, the customer needs evidence for the controls under its responsibility. Role assignments, access reviews, policy definitions, configuration records and audit logs all contribute to that record.

A service provider’s SOC 2 report, PCI DSS Attestation of Compliance, or ISO certificate serves as only one input to a broader compliance program. Under a shared-responsibility program, reliance on a provider’s control typically depends on the customer implementing the corresponding customer-side requirements. Responsibility matrices are particularly important during vendor due diligence because they show which controls belong to the provider, which belong to the customer and, in some cases, which are shared by both.

Although laws, regulations and standards use different terminology, many rely on the same underlying security controls. Identity and access management, encryption, data-level protection, logging, vulnerability management, retention, incident response and third-party oversight are necessary across multiple programs.

For compliance purposes, the implementation itself is only part of the requirement. Organizations also need records that show how a control was configured, reviewed and operated over time.

Identity and access management

Identity and access controls govern who can reach regulated data and under what conditions. Role-based access control (RBAC), least privilege, multi-factor authentication and periodic access reviews are common examples.

The evidence usually comes from the systems enforcing those controls. Role assignments, authentication settings, access-review records and logs of privilege changes give auditors and internal reviewers something concrete to evaluate.

Data-level protection

For sensitive data that users or applications need to work with, controls such as data masking, tokenization and row-level restrictions limit what they can see or use. Protections should align with the organization’s policies for the data involved. Evidence may include masking-policy definitions, row-access policies, tokenization configuration and records showing where those controls are applied.

Encryption and key management

Encryption protects applicable data in transit and at rest, while key management governs the cryptographic material behind that protection. Reviewers typically look beyond whether encryption is enabled. Key ownership, rotation, access and revocation records help show how the control is managed over time.

Logging and monitoring

Logging and monitoring create a record of activity around regulated data: who accessed it, what changed, when an event occurred and which actions followed. For compliance, the key question is whether those security records are complete, reviewable and available for the required period. PCI DSS, for example, sets explicit requirements for retaining audit-log history, so an organization needs both the logging control and the historical record to support an investigation or assessment.

Retention and deletion

Retention and deletion controls govern the lifecycle of the regulated data itself. Policies define how long particular records should remain available, which legal or business exceptions apply, and when the data should be deleted or otherwise disposed of. Evidence here includes retention configurations, deletion records, disposal workflows and approved exceptions, all of which show that the organization is applying its lifecycle rules to the data in scope.

Vulnerability and configuration management

Security compliance also depends on the systems around the data. In Verizon’s 2026 Data Breach Investigations Report, exploitation of vulnerabilities accounted for 31% of breaches, overtaking credential abuse as the leading initial access vector. Vulnerability scanning, patching and configuration assessments identify weaknesses that could undermine otherwise well-designed access and data-protection controls. Typical evidence includes scan results, remediation tickets, configuration findings and records showing when identified issues were resolved.

Incident response

Incident-response controls govern how organizations detect, assess, contain and document security incidents, including decisions about regulatory notification. Evidence might include tested response plans, incident timelines, notification records and post-incident reviews.

Third-party risk

Service providers and other third parties often process, store or access regulated data, which brings their controls into the compliance picture as well. Third-party oversight deserves particular attention as organizations rely on more external services. Verizon found third-party involvement in 48% of breaches in its 2026 data set. Due diligence records, contracts, security attestations, shared-responsibility documentation and periodic reassessments provide evidence that third-party risks are being reviewed and managed.

A well-run compliance program links each stage. Scope determines which requirements apply, those requirements map to controls, controls have owners, and normal operation produces evidence.

1. Determine which requirements apply

Start with the organization’s data, locations, business activities, contracts and customers. From there, identify relevant legal obligations, industry standards, customer commitments and internal requirements. The output should be specific. “Comply with GDPR” is too broad for implementation, for example. “Restrict access to defined categories of personal data and retain evidence of access” points toward concrete controls.

2. Identify systems and regulated data in scope

Inventory your regulated and sensitive data, then trace the systems, applications, identities and third parties that store, process or access it. Scope changes over time. New pipelines, integrations, AI applications and regional deployments alter where data travels and which systems participate in processing, so discovery and classification belong in ongoing operations.

3. Map requirements to policies and controls

For each requirement, document the corresponding internal policy, operating control and expected evidence. A single control will often support several obligations. Instead of maintaining separate access-review processes for several frameworks, for example, an organization can map the relevant requirements to one well-defined access-review control and retain evidence once.

The resulting control map becomes the connective tissue of the program: auditors see why the control exists, engineers know what needs to operate, and control owners know which records have to be retained.

4. Assign control ownership

Each control needs an accountable owner, along with a review cadence and an escalation path. Ownership should include the evidence associated with the control. For a quarterly access review, for example, someone needs responsibility for completing the review, resolving inappropriate access and preserving the resulting approval or remediation records.

Roles will vary by organization. CISOs and security teams often own technical controls, privacy leaders oversee privacy obligations, and data owners or stewards make decisions about particular data sets. Clear boundaries reduce the chance that everyone assumes someone else is responsible.

5. Implement and enforce controls

Once the mappings and ownership are defined, apply the required controls to the systems and data in scope. Where possible, policy-driven enforcement reduces reliance on manual execution. Classification tags linked to masking or access policies, lifecycle rules tied to retention requirements and centralized authentication policies all provide more consistent enforcement than procedures someone has to remember to perform.

6. Collect evidence through normal operations

Routine operation should produce evidence: an access review should leave a review record, a policy update should appear in configuration history, a security detection should generate an alert and an investigation trail. Deletion workflows should record what was removed and when. Designing evidence into the control reduces the scramble before an audit, when teams otherwise spend time reconstructing historical proof from screenshots, tickets and individual systems.

7. Test controls and response processes

Testing checks whether the documented control works under realistic conditions. Technical controls as well as operational processes should be tested. Incident-response exercises, recovery tests and notification simulations expose gaps that aren’t obvious from a policy document, especially when several teams need to coordinate under a regulatory reporting deadline.

8. Reassess scope and control effectiveness

Systems evolve, vendors change and regulations shift. Periodic reassessment checks whether the control set still reflects the environment. Some standards specify a cadence. PCI DSS, for example, includes recurring scope-confirmation requirements. Significant architectural, application or business changes also provide a natural trigger for review.

Even a well-designed control map sits inside a complex environment that presents challenges. Several pressures deserve particular attention because they alter scope or compress the time available to respond.

Data sprawl and changing scope

As regulated data is used across more workloads, applications and regions, the compliance scope can change even when the data remains within a governed environment. New access paths, processing locations and downstream uses may introduce additional obligations or require existing controls to apply more broadly.

Keeping data within a governed environment reduces the need for unmanaged copies and gives security and compliance teams a more consistent place to apply classification, access and policy controls. Ongoing discovery and classification then help teams identify changes in scope as the environment evolves.

AI and new data access paths

AI applications introduce additional paths between users, services, tools and regulated data. In agent workflows, several identities may participate in a single task: the end user, the agent or application, the service account used to call a tool, and the identity recognized by a downstream system may all be different.

AI makes authorization and auditability more complex, so compliance teams need to understand which identity is acting at each step, which permissions are being exercised, whether the agent is acting on behalf of a user or under its own standing privileges, and which records tie those actions back to the workflow that initiated them.

Review should also cover the data itself. Which regulated data can the application retrieve? Which policies apply to that access? What record shows what the agent retrieved, which tools it invoked and what actions followed?

Different incident-reporting clocks

Incident-reporting requirements use different deadlines, and the event that starts the clock varies as well.

Reporting triggers shape how response teams document the incident timeline. Teams need to record when each applicable trigger occurs and calculate the corresponding deadline from that point.

Data residency and cross-border processing

Where regulated data is stored, processed and accessed influences some compliance obligations. In a multiregion architecture, replication, sharing and failover decisions need to account for location and transfer requirements alongside performance and resilience. Data inventories should include these location details rather than identifying only the data’s business owner or sensitivity.

Configuration and control drift

A control that passed an audit six months ago may no longer match today’s environment. New privileges get granted, policies change, integrations are introduced and services are reconfigured. Continuous posture assessment gives security and compliance teams visibility between formal reviews, allowing them to identify changes before those changes persist into the next audit period.

Data security audits test whether required controls are designed appropriately and operating as expected. Internal audits give organizations a way to identify gaps before they reach an external assessor or regulator, while external audits and assessments provide independent evaluation against a particular standard, contractual requirement or regulatory obligation.

The scope and evidence vary with the engagement. For example, an internal audit might review access approvals, encryption settings, retention configurations and remediation records across a defined set of systems. Each external assessment, such as SOC 2 or ISO/IEC 27001, has its own specific criteria and evidence requirements. Regulatory examinations focus on the obligations established by the applicable law or rule.

Audit readiness depends heavily on what happens between audits. When control owners retain access reviews, policy changes, security findings, remediation records and other evidence as part of normal operations, teams can quickly retrieve a record of control performance without having to reconstruct it shortly before an assessment. Periodic internal reviews also give teams a chance to test that evidence, resolve gaps and confirm that changes in systems or compliance scope have been reflected in the control set.

Snowflake provides data governance, security and monitoring capabilities that align with the requirement-to-control-to-evidence model, while customers are responsible for their own compliance obligations and configurations.

• Discover and classify sensitive data: Snowflake Horizon Catalog and sensitive data classification help identify regulated information and apply metadata that can drive governance policies. That gives teams a consistent basis for deciding where masking, access and retention controls belong.
• Enforce access and data protection policies: RBAC, masking policies, row access policies and tag-based masking help restrict who can access sensitive data and what they can see. Network and authentication policies narrow access further, while storage lifecycle policies support retention requirements.
• Protect data and monitor activity: Snowflake encrypts data in transit and at rest, with Tri-Secret Secure available for customers that need additional control over key management. Access History records data access at the SQL statement level, while Trust Center scanners and posture reports (public preview) surface security findings, configuration changes and other evidence relevant to compliance reviews.
• Use Snowflake assurance within the shared-responsibility model: Snowflake publishes certifications and attestations by region, which customers can use during vendor due diligence and audits. Those materials cover Snowflake-operated controls, while customer-specific configurations, policies and evidence remain the customer’s responsibility.

To learn more about how Snowflake approaches platform security, visit the Snowflake Security Hub.

Regulations and standards describe obligations in different ways, and security teams ultimately have to implement those obligations in systems, policies and operating processes. Mapping each requirement to a policy, control owner and body of evidence gives teams a practical structure for doing that work. As systems and requirements change, the map provides a way to reassess scope, update controls and determine whether the available evidence still supports the organization’s compliance obligations.