Minimum access, minimum data

Statement

Users and systems should have only the access they need and receive only the data they use

What this means in practice

Access to data is granted on a least-privilege basis. Users and systems receive the minimum permissions required to perform their function and are exposed only to the data they actually need. Broad, default-open access is replaced with deliberate, scoped grants that are reviewed and revoked as roles and requirements change. This applies equally to human users, service accounts, API consumers, and automated processes.

Data returned by queries, APIs, and interfaces is filtered to what the consumer requires. Over-fetching entire records or exposing fields beyond the scope of the request is avoided by design.

Why this matters

Excessive access increases the blast radius of security incidents, raises compliance risk, and makes it harder to audit who can see or change what. Limiting access reduces the attack surface, simplifies compliance with regulations such as GDPR, and ensures that data exposure is proportionate to the task at hand. It also builds trust with clients and end users by demonstrating that their data is handled with discipline.

Practices that meet this principle

Apply role-based or attribute-based access control with permissions scoped to specific functions
Default to deny; grant access explicitly rather than revoking it retroactively
Return only the fields and records a consumer requires through API design and query scoping
Review and recertify access grants on a regular schedule
Log and monitor access patterns to detect anomalies or over-permissioned accounts
Include access control design as a mandatory element of architecture and security reviews

Validation

A project meets this principle when:

Access control is implemented with least-privilege permissions for all users and systems
APIs and data interfaces return only the data required by the consumer
OR:
No user or system account has broader access than its function requires