ASD ISM 1255 Restrict database content access by user duties and functions
What it says
Database users' ability to access, insert, modify and remove database contents is restricted based on their duties or functions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEach database user can only read, add, change or delete the data their job actually requires, so nobody holds broader rights than their duties justify.
Databases hold an organisation's most valuable and sensitive records, and a database user account is often the most direct route to them. This control says that what each database user can do with the contents (read it, insert new records, modify existing records, or remove records) must be limited to what their duties or functions genuinely need. A reporting analyst who only ever reads data should not be able to delete tables; an application service account that inserts orders should not be able to alter payroll records. Why it matters: when database rights are broader than the job requires, a single mistake, a compromised credential or a disgruntled insider can expose, corrupt or destroy far more data than they had any business touching. Restricting access to the four operations (access, insert, modify, remove) by duty or function shrinks the blast radius of both accidents and attacks, and it keeps sensitive contents away from people who have no need to see them.
Free. Save your status, tasks and notes.
Why it matters
Without duty-based restrictions, over-privileged database users can view sensitive records they have no need for, or accidentally or deliberately insert, alter or delete data outside their remit. The consequences include breaches of personal or classified information, corrupted or lost business records, fraud through unauthorised data changes, and an attacker who compromises any one account gaining broad control of the database contents.
How to implement
Database owners and administrators define a set of database roles that reflect actual duties (for example read-only, read/insert, read/insert/modify, and full data management) and document which job functions map to each role.
Database administrators grant SELECT, INSERT, UPDATE and DELETE rights (or their equivalents) to roles only, then assign users and service accounts to roles; they remove any direct per-user grants so all access flows through the duty-based model.
Application owners configure each application or integration service account with the minimum data operations it needs, for example insert-only for an ingestion process or read-only for a reporting tool, rather than reusing a broadly privileged account.
Data owners use views, schemas or row- and column-level restrictions to confine users to the subset of contents relevant to their function, so that a role's read or modify rights do not extend to unrelated or sensitive tables.
Database administrators adjust or revoke a user's access, insert, modify and remove rights whenever that user's duties or functions change, so the restrictions continue to reflect what each role actually requires; as supporting good practice, they can also compare current grants against documented duties from time to time and remove anything that no longer matches.
Keep it running
Day to day, this control lives in the database's permission model. Access is granted through roles or groups that map to duties (for example read-only reporting, application read/write, data steward, database administrator) rather than to individual convenience. New database users are provisioned into the role that matches their function, and the right to insert, modify or remove data is withheld unless the duty requires it.
Staff changes are the usual point of failure. When someone changes job or leaves, or when an application is retired, their database permissions must be adjusted or revoked promptly. Database administrators should periodically compare current grants against documented duties and remove anything that has crept beyond the role, including direct grants that bypass the role model. Requests for elevated rights (such as the ability to modify or remove contents) should be justified against the requester's function and approved before being granted.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Request the database role and permission matrix that maps job functions to the data operations (access, insert, modify, remove) each is permitted.
Look at
Check that each role's rights are explained by the duties it serves and that no role grants modify or remove rights without a stated functional need.
Good evidence
A current, approved matrix exists, roles are duty-based, and destructive operations are limited to a small number of clearly justified functions.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export of actual grants from the database management system for a sample of databases holding sensitive data.
Look at
Compare the live grants against the documented matrix and look for direct per-user grants, broad public grants, or accounts with full rights.
Good evidence
Live permissions match the documented model, access is granted through roles, and any exceptions are recorded and approved.
- Check 3 of 5What an auditor asks for
Ask for
Select a sample of database users and service accounts and ask what each one's job function or purpose is.
Look at
Confirm that each account's ability to read, insert, modify or remove contents lines up with that function, paying attention to reporting users and integration accounts.
Good evidence
Read-only users cannot change data, application accounts hold only the operations they need, and nobody holds delete rights without a reason.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the organisation keeps each database user's access, insert, modify and remove rights aligned with their current duties or functions as those change over time.
Look at
Select a few users whose duties or functions have changed and check whether their database rights were adjusted to match; note, as supporting good practice rather than a requirement of this control, whether grants are periodically compared against documented duties.
Good evidence
Rights track current duties, with excess insert, modify or remove rights taken away when a user's function changes, and any periodic comparison that is performed confirms the restrictions remain appropriate.
- Check 5 of 5What an auditor asks for
Ask for
Ask how a request for elevated database rights, such as the ability to modify or remove contents, is justified and approved.
Look at
Review recent requests and approvals to see whether the justification references the requester's duties and whether approval preceded the grant.
Good evidence
Elevated rights are granted only with a documented functional justification and approval, and are time-limited or reviewed where appropriate.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-1255 requires restricting what database users can do to database contents based on their duties or functions. Annex A 5.15 requires establishing and implementing access control rules for physical and logical access to information and associated assets based on business and security requirements. ISM-1255 fits within Annex A 5.15 as a specific logical access rule for database-level permissions and actions.
This control partially meets A.5.18.
ISM-1255 requires restricting database users' read/write/delete capabilities to what their duties or functions require. Annex A 5.18 requires access rights to information assets to be provisioned, reviewed, modified and removed according to the organisation's access control rules, covering the access-rights lifecycle across many asset types. ISM-1255 is a specific instance of Annex A 5.18 focused on database content operations rather than all information assets and all access-rights management processes.
This control partially meets A.8.3.
Annex A 8.3 requires access to information and associated assets to be restricted in line with access control policy. ISM-1255 relates by requiring database user permissions (access/insert/modify/remove) to be restricted according to work duties, which is a concrete least-privilege application. Annex A 8.3 is broader as it applies to all asset types and is not limited to database CRUD permissions.
This control supports A.5.3.
ISM-1255 requires duty-based restriction of database operations so users only have database permissions aligned to their role. Annex A 5.3 requires segregation of duties to prevent conflicting responsibilities being held by the same person. Implementing ISM-1255 supports Annex A 5.3 by enforcing SoD in the database layer (e.g., separating data entry from approval via permissions), but Annex A 5.3 also covers organisational process design beyond database access controls.
ASD Essential Eight: 1 mapping
This control partially meets E8-RA-ML3.1.
ISM-1255 requires restricting database content access (read/insert/modify/remove) by user duties and functions. E8-RA-ML3.1 requires privileged access across systems, applications and data repositories to be limited to what is necessary for duties, which includes but is not limited to databases. ISM-1255 is a concrete database-focused application of the broader least-privilege requirement in E8-RA-ML3.1.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.