ASD ISM 1268 Enforce need-to-know access in databases
What it says
The need-to-know principle is enforced for database contents through the application of minimum privileges, database views, database roles and data tokenisation.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnly authorised users can access database contents by using specific privileges, roles, and techniques to protect the data.
This control ensures that only the right people can access the information in your databases. Just like you wouldn't want everyone reading your private diary, businesses need to protect sensitive data from being seen by those without a good reason. If it's not done, unauthorised access could lead to data leaks, hurting your business's reputation and potentially resulting in financial loss.
Free. Save your status, tasks and notes.
Why it matters
Without database need-to-know controls (least privilege, roles/views, tokenisation), users may access sensitive records outside their duties, increasing breach risk.
How to implement
The database administrator should identify which users genuinely need access to specific parts of the database.
They can do this by meeting with each department to understand their data needs and then restricting access to just that required information.
IT security staff should set up database views to limit what data users can see.
This involves creating tailored, read-only windows that show only the necessary information for jobs, keeping other data hidden.
The IT team should assign roles within the database software that match job responsibilities.
They can do this by mapping organisational roles to database roles, ensuring each person only has the access they need to do their job.
Database administrators should implement data tokenisation to protect sensitive information.
They can replace sensitive data with tokens or placeholders and keep the actual data in a secure location, only revealing it to those with special access.
Managers should regularly review and update access permissions.
This involves scheduling regular check-ins with the IT team to ensure that access rights are current and that no one has access to more information than they need.
Keep it running
Review database roles and privileges, enforce access via least-privilege roles and views, and apply tokenisation to limit exposure of sensitive fields to authorised users.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of user access privileges: Request a document that lists all database users and their level of access.
Look at
Whether users only have access to what they need to do their jobs.
Good evidence
Clear evidence that each user's access matches their role and responsibilities, and unnecessary access has been removed.
- Check 2 of 5What an auditor asks for
Ask for
To see the database view configurations: Request examples of how database views have been set up.
Look at
Whether sensitive information is being appropriately hidden from those who don't need it.
Good evidence
Configurations should show only the essential information, with sensitive data obscured.
- Check 3 of 5What an auditor asks for
Ask for
Records of role assignments: Request documentation of role mappings and assignments.
Look at
How well roles in the database align with job descriptions.
Good evidence
Documentation should clearly map database roles to organisational roles, with approvals for any changes.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of tokenisation methods: Request records of how tokenisation is implemented for sensitive data.
Look at
Descriptions of tools or methods used and confirmation that these are active.
Good evidence
Evidence of ongoing use of tokenisation methods, with appropriate safeguards in place.
- Check 5 of 5What an auditor asks for
Ask for
Minutes from recent access reviews: Request minutes or notes from meetings where access permissions were reviewed.
Look at
What changes were made and why.
Good evidence
Minutes show regular reviews with actions taken to adjust access as needed.
Mappings
Closest match in ISO/IEC 27001: A.8.3, Restrict access to information and assets, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.8.3.
Annex A 8.3 requires restricting access to information and assets based on an established access control policy. ISM-1268 implements this for databases by enforcing need-to-know via minimum privileges, views, roles and tokenisation to constrain access to database contents. Annex A 8.3 is broader because it covers all information assets and access mechanisms, not just database-layer controls.
This control partially overlaps A.5.18.
ISM-1268 requires enforcing need-to-know for database contents using minimum privileges, database roles/views, and tokenisation. ISO/IEC 27001:2022 Annex A 5.18 covers provisioning, reviewing, modifying and removing access rights, which is the access-rights lifecycle needed to keep database roles and privileges aligned to need-to-know. ISM-1268 provides concrete database enforcement mechanisms, while Annex A 5.18 focuses on governance and ongoing management of those rights.
This control partially overlaps A.8.11.
Annex A 8.11 requires organisations to apply data masking for sensitive information in line with access control policy, business needs, and applicable legislation. ISM-1268 relates by requiring database-level need-to-know enforcement using mechanisms such as minimum privileges, database views/roles and explicitly includes data tokenisation (a form of masking) to limit exposure of sensitive database contents. The overlap is specifically around using masking/tokenisation to reduce sensitivity of data presented to users, but ISM-1268 is focused on database access enforcement whereas Annex A 8.11 is broader and can apply to masking across systems, outputs, and contexts beyond databases.
This control depends on A.5.34.
ISM-1268 requires enforcing need-to-know for database contents and includes controls like minimum privileges and tokenisation to limit exposure of sensitive data. ISO/IEC 27001:2022 Annex A 5.34 requires meeting privacy and PII protection requirements, which commonly necessitates restricting who can access PII stored in databases and reducing exposure via tokenisation/masking. ISM-1268 is a technical access enforcement approach, while Annex A 5.34 is a compliance-driven requirement that ISM-1268 helps satisfy for database-held PII.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML3.1.
E8-RA-ML3.1 requires limiting privileged access to systems, applications, and data repositories to only what is necessary for duties. ISM-1268 enforces need-to-know within databases using minimum privileges and mechanisms like views, roles, and tokenisation, which directly implements least privilege at the data layer. The overlap is on limiting access to data repositories, but ISM-1268 is database-specific and includes data protection mechanisms beyond privileged-access scoping alone.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.