Category: Access Control

Column-Level Security

Also known as: CLS, Field-Level Security, Column-Level Access Control

Simply put

Column-level security is a control that restricts who can see or use the data held in specific columns of a table or view, rather than restricting access to the whole table. For example, one group of users might see a customer table without a column containing sensitive identifiers, while another group with greater privileges can view that column. This differs from row-level security, which limits which records (rows) a user can access.

Formal definition

Column-level security governs access to individual columns within a table or view, and its enforcement is typically independent of view definitions, so that restrictions apply whether or not a view is authorized (as described for Google BigQuery). Implementations vary by platform: in Snowflake, column-level security is applied by attaching a masking policy to a column in a table or view, controlling the values returned to a given user or role; in Microsoft Power Platform, column-level (field-level) security configurations are organization-wide and applied to specific columns. This entry describes the access-control concept and platform-specific behaviors named in the evidence only. It does not cover row-level security mechanics beyond the noted contrast, encryption at rest or in transit, key management, or the question of whether masking or restriction alone renders underlying data non-personal for regulatory purposes; those determinations depend on jurisdiction, implementation, and context.

Why it matters

Column-level security addresses a common gap in access control: a user may have a legitimate need to work with a table while having no business justification to see every field within it. Sensitive identifiers, contact details, or other regulated data often sit alongside operational fields that many users need. By restricting access at the column level rather than the whole table, organizations can apply the principle of least privilege more precisely, allowing broad access to a dataset while keeping specific columns hidden or masked from users who lack sufficient privileges.

This granularity supports data minimization and need-to-know practices that governance and security programs generally expect. It also helps separate the concerns of who can query a dataset from what values are actually returned to them, which is useful when the same table serves multiple audiences with different entitlements. Column-level security is an information security control that operates within a platform; it does not, on its own, determine whether the underlying data remains personal data for regulatory purposes. Whether masking or restricting a column changes the legal characterization of the data depends on jurisdiction, implementation, and context, and that determination is out of scope for this control.

Because its behavior differs across platforms, teams should not assume that column-level security works identically everywhere. In Google BigQuery, for example, its enforcement on views is independent of whether the view is an authorized view. In Snowflake, it is applied by attaching a masking policy to a column. In Microsoft Power Platform, column-level (field-level) security configurations are organization-wide. These distinctions matter when designing controls and when demonstrating, with evidence, that access is appropriately restricted.

Who it's relevant to

Privacy engineers and data platform teams

Those configuring access controls on data warehouses and platforms use column-level security to enforce least privilege and need-to-know at the field level. They should account for platform-specific behavior, such as how BigQuery enforces column-level security independently of authorized views, or how Snowflake relies on masking policies attached to columns.

Data governance and stewardship leads

Governance teams responsible for defining which fields are sensitive and who may access them can use column-level security as one control that operationalizes access policy. Accountability under governance frameworks generally requires demonstrable evidence of how access is restricted, not merely stated intent, so how these controls are configured and documented matters.

Data protection and compliance officers

Those assessing data minimization and access controls should treat column-level security as an information security measure rather than a determination of legal status. Whether masking or restricting a column affects whether data is considered personal data depends on jurisdiction, implementation, and context, and is not resolved by the control alone.

Security architects

Architects designing layered access controls can combine column-level security with other measures. Because it addresses which fields are visible rather than which rows are accessible, it is complementary to, and distinct from, row-level security, and its enforcement details differ across BigQuery, Snowflake, and Microsoft Power Platform.

Inside CLS

Column-Level Access Control

A mechanism that restricts visibility of, or operations on, specific columns within a database table or dataset, so that a given user or role can access some attributes of a record while being denied others. It operates at a finer granularity than table-level or row-level controls.

Role- or Attribute-Based Enforcement

The policy layer that determines which principals may read or modify particular columns, typically expressed through roles, groups, or attribute-based conditions evaluated at query time. This is generally a component of information security access control rather than a substitute for broader governance.

Column-Level Masking or Redaction

Techniques that transform or hide values in restricted columns for unauthorized users, for example returning null, redacted, or masked output. Masking may reduce exposure but does not, on its own, render the underlying data non-personal.

Sensitivity Classification of Columns

The identification and labeling of columns that hold personal data, special category or sensitive data, or otherwise regulated attributes, which informs which columns warrant restriction. Classification is a governance activity that supports, but is distinct from, the security enforcement itself.

Auditing and Evidence of Enforcement

Logging of access to and configuration of column-level controls, providing demonstrable evidence that restrictions operate as intended. Accountability under governance frameworks generally requires such evidence rather than a stated policy alone.

Common questions

Answers to the questions practitioners most commonly ask about CLS.

Does applying column-level security to a field make that data no longer personal data?

No. Restricting who can view or query a column controls access to the data; it does not change its legal classification. Personal data that is masked, restricted, or hidden through column-level controls generally remains personal data, and where the underlying values can still be linked to an individual, obligations under applicable regimes such as the EU GDPR or UK GDPR continue to apply. Column-level security is an access control, not a de-identification technique that removes data from scope.

Is column-level security an information security measure or a data governance measure?

It sits at the overlap of both, but the two roles should not be collapsed. As a security control, column-level security supports confidentiality by limiting who can read specific fields. As a governance matter, deciding which columns warrant restriction depends on data classification, ownership, and stewardship decisions about sensitivity and policy. The governance layer defines what should be protected and why; the security layer enforces it. Neither alone is sufficient, and one does not substitute for the other.

How does column-level security relate to row-level security, and can they be used together?

Column-level security restricts access to specific fields (attributes) across records, while row-level security restricts access to specific records based on their content or the requesting user's attributes. They address different dimensions of the same table and are frequently combined so that a given user sees only the permitted rows and, within those rows, only the permitted columns. This entry does not cover the specific policy syntax or enforcement mechanics of any particular database or platform.

Should column-level restrictions rely on masking, or on denying access entirely?

That depends on the use case and the sensitivity determined during classification. Some scenarios call for outright denial so that a restricted column is not returned at all, while others use masking or redaction so that a column can be referenced for joins or analytics without exposing the actual values. The appropriate approach is context-dependent, and this entry does not evaluate which masking or tokenization method is suitable for a given regulatory context. Note that masking or tokenizing a column does not, by itself, render the underlying data non-personal.

Who is accountable for defining which columns require restriction?

Responsibility for identifying sensitive columns typically rests with data owners and stewards working alongside privacy and security functions, informed by the organization's data classification scheme. Accountability under governance frameworks generally requires demonstrable evidence, so the rationale for each restriction, the approvals, and the enforcing policy should be documented rather than merely asserted. This entry does not prescribe a specific organizational structure, which varies by enterprise.

How can an organization demonstrate that column-level security is working as intended?

Generally, this involves logging and periodically reviewing who accessed which columns, testing that restrictions behave as configured for different user roles, and reconciling the enforced controls against the documented classification and policy. Demonstrable evidence, such as access logs, configuration records, and review outcomes, supports accountability more effectively than stated intent. This entry does not address specific retention periods for such logs or the enforcement consequences of control failures under any particular regime.

Common misconceptions

Applying column-level security or masking to a sensitive column makes that data non-personal and takes it out of regulatory scope.

Restricting or masking access controls who can see a value; it does not change the nature of the underlying data. Masked, encrypted, or tokenized data typically remains personal data where the values or the mapping can still be associated with an individual. Only irreversible anonymization would generally move data out of scope, and column-level security is not anonymization.

Column-level security is purely a data governance control that satisfies classification and stewardship obligations by itself.

Column-level security is primarily an information security access control focused on confidentiality. It overlaps with governance, since sensitivity classification informs which columns to protect, but it does not by itself deliver data ownership, stewardship, lineage, catalog, or data quality outcomes that governance covers.

Column-level security is interchangeable with row-level security and column masking as if they were one feature.

These are distinct controls. Row-level security filters which records a principal can see, column-level security filters which attributes across records are accessible, and masking transforms values rather than removing the column. They are frequently combined but address different exposure risks and should not be conflated.

Best practices

Classify columns by sensitivity, distinguishing personal data from special category or sensitive data, before designing controls, and treat this classification as an input maintained under your governance program.

Define column-level access through roles or attributes on a least-privilege basis, granting access to individual columns only where there is a demonstrable operational need.

Do not rely on masking, encryption, or tokenization at the column level to treat data as anonymized or out of regulatory scope; continue to handle it as personal data unless an irreversible anonymization assessment supports otherwise.

Combine column-level controls with row-level and other access mechanisms where appropriate, and document how each layer addresses a distinct exposure rather than assuming one control covers all cases.

Enable and retain audit logging of both access to restricted columns and changes to the control configuration, so you can produce demonstrable evidence of enforcement for accountability purposes.

Review column classifications and access grants periodically and after schema changes, since new columns may introduce sensitive attributes that fall outside existing restrictions.

Coordinate column-level security with, but not as a replacement for, wider obligations such as lawful basis, retention, and cross-border transfer, which fall outside the scope of this control.