Compliance and Privacy

Casabase Cube provides administrative reporting capabilities that help organizations review data governance, privacy, security, and access-control posture.

These capabilities provide visibility into areas such as:

• Cube data classification
• Security configuration
• User access
• Audit coverage
• Data inventory
• Data usage
• Application data-handling posture
• Governance recommendations

They are designed to support an organization’s broader compliance and privacy processes.

Casabase Cube does not determine whether an organization is compliant with a particular regulation or standard. Compliance depends on the organization’s complete technical environment, policies, procedures, controls, and regulatory requirements.

Administrative Reporting

Three administrative capabilities are particularly useful for compliance and privacy reviews:

Capability	Purpose
Data Inventory	Inventory cubes and review their classification, security posture, and usage.
Privacy Report	Review application data handling, classification, security coverage, audit history, and governance recommendations.
Access Review	Review application access and row-level security assignments.

Together, these capabilities help answer fundamental governance questions:

What data is managed?
        │
        ▼
Data Inventory


How does the application handle data?
        │
        ▼
Privacy Report


Who has access?
        │
        ▼
Access Review


What activity occurred?
        │
        ▼
Audit Log

Data Inventory

Use:

CALL CUBE.GET_DATA_INVENTORY();

to retrieve an inventory of the cubes managed by Casabase Cube.

The inventory includes:

Column	Description
CUBE_NAME	Name of the cube.
DATA_TABLE	Data table associated with the cube.
DATA_CLASSIFICATION	Current classification assigned to the cube.
DIMENSION_COUNT	Number of dimensions associated with the cube.
HAS_SECURITY	Indicates whether row-level security is configured for the cube.
LAST_QUERIED	Most recent query activity associated with the cube.

This provides a consolidated view of the data assets represented by Casabase Cube.

Reviewing Classification

DATA_CLASSIFICATION identifies the governance classification assigned to each cube.

Supported classifications are:

PUBLIC
INTERNAL
CONFIDENTIAL
RESTRICTED

For example:

CUBE_NAME             DATA_CLASSIFICATION
--------------------  -------------------
PUBLIC_METRICS        PUBLIC
SALES_ANALYTICS       INTERNAL
FINANCE               CONFIDENTIAL
EXECUTIVE_REPORTING   RESTRICTED

Classification helps administrators identify which cubes warrant additional governance or access review.

Classification itself does not enforce security.

See Data Classification for classification management and behavior.

Reviewing Security Posture

The Data Inventory also reports:

HAS_SECURITY

This allows administrators to compare the sensitivity of a cube with whether row-level security has been configured.

For example:

CUBE_NAME             CLASSIFICATION   HAS_SECURITY
--------------------  ---------------  ------------
PUBLIC_METRICS        PUBLIC           FALSE
SALES_ANALYTICS       INTERNAL         FALSE
FINANCE               CONFIDENTIAL     TRUE
EXECUTIVE_REPORTING   RESTRICTED       TRUE

A sensitive cube without row-level security should be reviewed:

CONFIDENTIAL / RESTRICTED
            +
     HAS_SECURITY = FALSE
            │
            ▼
     Administrative Review

This does not automatically indicate a security problem.

Access can also be controlled through Snowflake roles and Casabase Cube application roles. The purpose of the review is to confirm that the configuration is intentional and appropriate for the organization’s requirements.

HAS_SECURITY = TRUE should also not be interpreted as proof that every user is restricted.

Casabase Cube row-level security is opt-in per user. A user with application access but no active security rules remains unrestricted by Casabase Cube row-level security.

For sensitive cubes, administrators should therefore review both:

Cube-Level Security Configuration
              +
Individual User Security Coverage

See Access Control for the complete security model.

Reviewing Data Usage

LAST_QUERIED provides information about recent cube usage.

This can help identify cubes that may no longer be actively consumed.

For example:

CUBE_NAME      CLASSIFICATION   LAST_QUERIED
-------------  ---------------  -------------------
LEGACY_PLAN    CONFIDENTIAL     2025-11-14
FINANCE        CONFIDENTIAL     2026-08-22
SALES          INTERNAL         2026-08-23

A long-unused cube can be reviewed to determine whether it should:

• Remain available
• Retain its current access
• Be archived according to organizational policy
• Be decommissioned
• Be included in continued compliance and access reviews

The decision to retain or remove data remains an organizational governance decision.

Privacy Report

Use:

CALL CUBE.GET_PRIVACY_REPORT();

to generate the Casabase Cube privacy and governance report.

The procedure returns a JSON VARIANT suitable for use as supporting evidence during a compliance or governance review.

The report contains these primary areas:

Section	Purpose
summary	Total cubes, classification coverage, and row-level security coverage.
data_handling	Casabase Cube’s application data-handling posture.
audit_log	Audit-record count and span of retained audit history.
recommendations	Governance gaps detected by the application, such as unclassified cubes.
report_date	Date the report was generated.

Conceptually:

Cube Inventory ──────────┐
                         │
Classification ──────────┤
                         │
Security Coverage ───────┼──► GET_PRIVACY_REPORT()
                         │
Audit History ───────────┤
                         │
Data-Handling Posture ───┤
                         │
Governance Checks ───────┘

Data-Handling Posture

The Privacy Report explicitly describes four aspects of Casabase Cube’s data-handling posture:

data_egress           NONE
external_connections  NONE
pii_collection        NONE
telemetry             DISABLED

These values have specific meanings.

Data Egress

data_egress = NONE

Casabase Cube does not send customer data outside the customer’s Snowflake account.

Application processing occurs against data within Snowflake.

External Connections

external_connections = NONE

Casabase Cube does not make outbound network connections.

The Native App does not require an external Casabase-hosted application service to process cube operations.

PII Collection

pii_collection = NONE

Casabase Cube does not collect personal data for the provider.

This statement describes application collection behavior. It does not mean that a customer’s own cube data cannot contain information that the customer considers personal or sensitive.

Customers remain responsible for classifying and governing the data they place in their Snowflake environment.

Telemetry

telemetry = DISABLED

Casabase Cube does not send usage telemetry to the provider.

Application audit information remains within the customer’s Snowflake environment.

Processing Boundary

Core Casabase Cube processing occurs inside the customer’s Snowflake account.

This includes:

Dimension Builds
      │
Queries
      │
Formula Evaluation
      │
Scheduled Materialization
      │
      ▼
Customer Snowflake Account

The application operates on the customer’s Snowflake compute, against data available within the customer’s Snowflake environment.

This architecture is relevant to common vendor-review questions concerning:

• Data residency
• Data egress
• Provider access
• External processing
• Telemetry
• Confidentiality boundaries

See Data Storage & Boundaries for the architectural model.

AI Features

If AI features are enabled, Cortex Agent interactions execute through Snowflake Cortex within the customer’s Snowflake environment and region.

Casabase Cube itself does not establish an external network connection for this functionality.

The optional application grant:

SNOWFLAKE.CORTEX_USER

enables supported Cortex functionality.

See Roles and Privileges and Integration Points.

Using the Privacy Report

The Privacy Report can be used during reviews to identify conditions that warrant administrative attention.

Examples include:

• Cubes without a classification
• Sensitive cubes requiring access review
• Row-level security coverage requiring validation
• Governance information requiring follow-up
• Audit-history coverage requiring review
• Data-handling conditions that should be compared with organizational policy

The report provides information and recommendations to support review.

It does not automatically change cube configuration or security posture.

Privacy Report vs. Compliance Certification

The Privacy Report should not be interpreted as a compliance certification.

For example, generating:

CALL CUBE.GET_PRIVACY_REPORT();

does not by itself establish compliance with frameworks or regulations such as:

SOC 2
ISO 27001
GDPR
CCPA
HIPAA
PCI DSS

Instead, the report provides application-level information that an organization can use as evidence or input within its broader compliance processes.

Conceptually:

Casabase Cube
Administrative Evidence
          │
          ▼
Organization's Controls
Policies and Procedures
          │
          ▼
Compliance Program
          │
          ▼
Assessment / Audit

The applicable requirements and conclusions remain the responsibility of the organization and its auditors or assessors.

Evidence for a Compliance Review

A reviewer may request evidence showing the application’s access, governance, and activity posture.

Useful Casabase Cube evidence includes the following.

Administrative Capability

To identify the Snowflake account roles that hold administrative capability:

SHOW GRANTS OF APPLICATION ROLE
    CASABASE_CUBE.CUBE_ADMIN;

Substitute your installed application name for:

CASABASE_CUBE

where appropriate.

Application Privileges

To review what the Native App is permitted to do:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

This can be used to verify application-level Snowflake grants such as:

READ SESSION
EXECUTE MANAGED TASK

and other customer-granted object access.

Classification and Security Coverage

Use:

CALL CUBE.GET_DATA_INVENTORY();

to review classification and cube-level security coverage.

Active Security Rules

Use:

SELECT
    CUBE_NAME,
    DIM_NAME,
    USER_NAME,
    MEMBER_NAME,
    UPDATED_BY,
    UPDATED_DATE
FROM CASABASE_CUBE.CONFIG.SECURITY
WHERE ACTIVE = TRUE
ORDER BY
    CUBE_NAME,
    DIM_NAME,
    USER_NAME;

to review active row-level security assignments.

Activity History

Use:

CALL CUBE.EXPORT_AUDIT_LOG(
    '2026-01-01'::TIMESTAMP_LTZ,
    '2026-03-31'::TIMESTAMP_LTZ,
    NULL,
    NULL,
    10000
);

to export application activity for a review period.

Adjust the dates and filters to match the period being reviewed.

See Audit Log for filtering and retention.

Access Review

A meaningful access review should consider two separate layers:

Application Access
       │
       └── Snowflake / Application Roles


Data Restrictions
       │
       └── Casabase Cube Security Rules

Reviewing only security rules is not sufficient to determine who can access Casabase Cube.

Similarly, reviewing only application-role grants does not identify the row-level scope applied to individual users.

What to Review

A periodic access review should answer questions such as:

• Who currently has access to Casabase Cube?
• Which Snowflake roles receive CUBE_PUBLIC?
• Which Snowflake roles receive CUBE_ADMIN?
• Which users inherit those roles?
• Which users have active row-level security rules?
• Which users have application access but no active security rules?
• Which dimensions are secured?
• Which hierarchy branches are users permitted to access?
• Are administrative privileges still required?
• Are obsolete users or service identities still present?
• Does access remain appropriate for the cube’s classification?

The last question connects access review with Data Classification.

For example:

Cube Classification
        │
        ▼
RESTRICTED
        │
        ▼
Review Application Access
        │
        ▼
Review Security Rules
        │
        ▼
Identify Unrestricted Users
        │
        ▼
Confirm Business Need

Access Review and Opt-In Security

Casabase Cube row-level security is opt-in per user.

Consider:

User A
├── CUBE_PUBLIC
└── Active ENTITY Rule

Casabase Cube row-level security applies to User A.

Now consider:

User B
├── CUBE_PUBLIC
└── No Active Security Rules

User B is not restricted by Casabase Cube row-level security.

This does not necessarily mean User B has inappropriate access. The user may legitimately require unrestricted cube access.

However, that access should be understood and intentional.

Required Unrestricted-User Review

For a secured cube, administrators should identify users who have queried the cube without active security rules.

For example:

SELECT DISTINCT
    a.USER_NAME
FROM CASABASE_CUBE.CONFIG.AUDIT_LOG a
WHERE a.CUBE_NAME = 'FINANCE'
  AND a.EVENT_TYPE = 'DATA_QUERY'
  AND NOT EXISTS (
        SELECT 1
        FROM CASABASE_CUBE.CONFIG.SECURITY s
        WHERE s.CUBE_NAME = a.CUBE_NAME
          AND s.USER_NAME = a.USER_NAME
          AND s.ACTIVE = TRUE
      )
ORDER BY 1;

Every returned user has queried FINANCE without active Casabase Cube row-level security rules.

For a CONFIDENTIAL or RESTRICTED cube, each such user should be reviewed to confirm that unrestricted access is intentional.

See Access Control.

Administrative Access Review

CUBE_ADMIN access should be reviewed separately from ordinary query access.

Administrators can modify application configuration and therefore should be limited to users whose responsibilities require those capabilities.

A review should verify:

Who has CUBE_ADMIN?
        │
        ▼
Do they still require it?
        │
        ▼
Is the Snowflake role path appropriate?
        │
        ▼
Retain or Remove Access

See Roles and Privileges for the application-role model.

Audit Information

Audit information provides another source of evidence during governance and compliance reviews.

Casabase Cube records significant application activity, including information about:

• User
• Operation
• Time
• Cube or affected object
• Outcome
• Execution timing

The audit log resides within the application in the customer’s Snowflake account.

It can help administrators investigate:

• Administrative activity
• Configuration changes
• Security changes
• Governance changes
• Query activity
• Upgrade activity
• Operational failures

For example, an access review may identify a changed security configuration, while the audit log can provide information about the administrative activity associated with that change.

See Audit Log for audit capabilities and retention.

Governance Review Workflow

A useful periodic governance review is:

Generate Data Inventory
        │
        ▼
Generate Privacy Report
        │
        ▼
Review Classifications
        │
        ▼
Identify Sensitive Cubes
        │
        ▼
Review Application Access
        │
        ▼
Review Row-Level Security
        │
        ▼
Review Unrestricted Users
        │
        ▼
Review Audit Information
        │
        ▼
Address Findings
        │
        ▼
Document Review

The exact frequency and evidence requirements should follow the organization’s own compliance and governance policies.

Reviewing a Sensitive Cube

For a CONFIDENTIAL or RESTRICTED cube, administrators should consider reviewing the following areas.

Classification

Confirm that the classification remains appropriate for the data represented by the cube.

Application Access

Review which Snowflake roles provide:

CUBE_PUBLIC

and:

CUBE_ADMIN

and determine which users inherit those roles.

Row-Level Security

Review:

• Whether security is enabled
• Which dimensions are secured
• Which users have active rules
• Which members or hierarchy branches those rules permit
• Which users have queried the cube without active rules
• Whether unrestricted users are intentional

Audit Activity

Review relevant administrative, security, and query activity where required.

Usage

Review:

LAST_QUERIED

to determine whether the cube remains actively used.

Together, these provide a more meaningful governance picture than classification or security status alone.

New Cube Review

When a new production cube is introduced, consider the following governance workflow:

Create Cube
    │
    ▼
Classify Data
    │
    ▼
Determine Access Requirements
    │
    ▼
Configure Roles
    │
    ▼
Configure Row-Level Security if Required
    │
    ▼
Validate Restricted and Unrestricted Access
    │
    ▼
Include in Ongoing Reviews

This helps ensure that governance considerations are addressed when the cube is introduced rather than added later.

User Offboarding

Compliance and access-review processes should also account for user offboarding.

When a user no longer requires access:

1. Remove or revoke the applicable Snowflake account-role access.
2. Verify that CUBE_PUBLIC or CUBE_ADMIN is no longer inherited.
3. Deactivate or delete obsolete Casabase Cube security rules as appropriate.
4. Retain the user’s audit history according to the configured retention policy.
5. Review administrative or audit information if required by organizational policy.

Deleting security rules alone is not sufficient to remove application access.

Because Casabase Cube row-level security is opt-in, removing a user’s final active security rule can remove the restriction and leave the user unrestricted if application access remains.

See Operational Tasks.

Evidence for Governance Reviews

Depending on organizational requirements, useful Casabase Cube evidence can include:

• Privacy Report output
• Data Inventory output
• Application-role grants
• Application account-level grants
• Active row-level security configuration
• Unrestricted-user review results
• Data classifications
• Audit records or audit exports
• Application version information
• Health and diagnostic information

Which artifacts should be retained, how frequently reviews should occur, and how long evidence should be preserved depend on the organization’s own policies and compliance requirements.

Recommended Practices

For compliance and privacy administration:

• Classify every production cube.
• Periodically review the Data Inventory.
• Generate the Privacy Report as part of governance reviews.
• Investigate sensitive cubes without row-level security.
• Do not assume HAS_SECURITY = TRUE means every user is restricted.
• Review users who have application access but no active security rules.
• Review CUBE_ADMIN access separately from normal query access.
• Review application-level Snowflake grants.
• Use audit information to investigate administrative and access activity.
• Review unused cubes and obsolete access.
• Perform access reviews according to organizational policy.
• Preserve review evidence where required by the organization’s compliance program.
• Treat Casabase Cube reporting as supporting evidence, not as a compliance certification.

Key Principle

Casabase Cube provides application-level evidence for questions such as:

What data do we have?
        │
        ▼
How is it classified?
        │
        ▼
How does the application handle it?
        │
        ▼
How is it protected?
        │
        ▼
Who can access it?
        │
        ▼
What activity occurred?

Its Native App architecture also establishes a clear processing boundary:

Customer Snowflake Account
        │
        ├── Customer Data
        ├── Casabase Cube
        ├── Query Processing
        ├── Formula Evaluation
        ├── Scheduled Processing
        └── Audit Information

No Casabase Cube Data Egress
No External Connections
No Provider Telemetry

These capabilities support governance, privacy, security, and compliance processes while leaving organizational policy, regulatory interpretation, and compliance conclusions with the organization.

Related Topics

• Administration Overview
• Roles and Privileges
• Access Control
• Data Classification
• Audit Log
• Operational Tasks
• Health and Diagnostics
• Data Storage & Boundaries
• Integration Points