ASD ISM 1255Restrict Database Content Access by User Duties and Functions
Official control statement
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.
In plain English
Each database user can only read, add, change or delete the data their job actually requires, so nobody holds broader rights than their duties justify.
What this means in practice
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.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskRequest the database role and permission matrix that maps job functions to the data operations (access, insert, modify, remove) each is permitted.Look atCheck 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.GoodA current, approved matrix exists, roles are duty-based, and destructive operations are limited to a small number of clearly justified functions.
- AskAsk for an export of actual grants from the database management system for a sample of databases holding sensitive data.Look atCompare the live grants against the documented matrix and look for direct per-user grants, broad public grants, or accounts with full rights.GoodLive permissions match the documented model, access is granted through roles, and any exceptions are recorded and approved.
- AskSelect a sample of database users and service accounts and ask what each one's job function or purpose is.Look atConfirm 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.GoodRead-only users cannot change data, application accounts hold only the operations they need, and nobody holds delete rights without a reason.
- AskAsk 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 atSelect 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.GoodRights 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.
- AskAsk how a request for elevated database rights, such as the ability to modify or remove contents, is justified and approved.Look atReview recent requests and approvals to see whether the justification references the requester's duties and whether approval preceded the grant.GoodElevated rights are granted only with a documented functional justification and approval, and are time-limited or reviewed where appropriate.
Cross-framework mappings
How ISM-1255 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 5.15 | ISM-1255 requires restricting what database users can do to database contents based on their duties or functions | |
| Annex A 5.18 | ISM-1255 requires restricting database users' read/write/delete capabilities to what their duties or functions require | |
| Annex A 8.3 | Annex A 8.3 requires access to information and associated assets to be restricted in line with access control policy | |
handshakeSupports(1)expand_less | ||
| Annex A 5.3 | ISM-1255 requires duty-based restriction of database operations so users only have database permissions aligned to their role | |
E8
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| E8-RA-ML3.1 | ISM-1255 requires restricting database content access (read/insert/modify/remove) by user duties and functions | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Database systems
See all Guidelines for database systems controls, or browse the full ASD ISM library.