Whole schema versus specific tables

Choose a data rule's correct scope by weighing operational simplicity against least privilege.

When to use this

• Use it before creating a data rule.
• Use it when an access request looks too broad.
• Use it in periodic governance reviews.

Before you start

• Understand the purpose of the access.
• List the tables genuinely needed.
• Check whether the schema holds sensitive data or unknown future tables.

Step by step

1. Choose Specific tables when the work has a clear objective.
2. Choose Whole schema when the function requires responsibility over the entire domain.
3. Use an expiry if the need is not permanent.
4. Use masks and filters when part of the data has to stay protected.
5. Review the final summary, weighing risk, scope, and duration.

What happens next

• The applied rule defines what appears and what can be queried.
• Changes are recorded for auditing.
• The decision can be reviewed and adjusted later.

Common errors

• Using a whole schema out of convenience: it can expose data beyond the need.
• Using specific tables for a broad function: it can create repetitive maintenance.
• Not considering future tables: a whole schema also covers new tables in the same set.

Good practice

• Document why you chose that scope.
• Prefer least privilege when in doubt.
• Pair a broad scope with periodic review.

Next steps

• Using expiry
• Granting specific tables
• Glossary