Contents
When change management is set up in an organisation, the scope usually stops at schema and data changes. Permission changes fall between the two: they alter no schema and no data, so no tool naturally owns them. Yet they are the most lasting and the quietest change made to a production database.
Why It Belongs to Nobody's Scope
A permission change stays out of scope because of a classification problem. The schema versioning tool does not carry it, because what gets versioned is table structure. The identity management system does not see it, because the right granted belongs to the database rather than to the application. The change process does not ask for it, because it has no tangible output like a column being added.
The result is that a GRANT statement usually follows this path: someone asks, a database administrator runs it, and that is the end of it. There is no request, no approval and no stated reason. This is the quietest power held by an organisation's most privileged people.
Three Things That Set It Apart
One: it has no symptom. A wrong schema change breaks the application and is noticed at once. A wrong data change shows up in a report. A permission granted too broadly breaks nothing; it merely lets someone see data they should not. Because there is no symptom, it never surfaces on its own.
Two: it is permanent. A schema change is superseded by the next release and a data fix runs once. A permission stays as granted. A right given years ago to solve a problem remains in force long after that problem has been forgotten.
Three: it accumulates. Looked at one by one, every permission is reasonable. Looked at in total after five years, the result is an access map nobody would have granted deliberately. This accumulation is called privilege creep, and it is where audits most often produce findings.
Why the Current Permission List Is Not Evidence
When an auditor asks about permissions, most organisations export the current permission list from the database. That list is correct, but it does not answer the question being asked.
| Question | Does the current list answer it |
|---|---|
| Who has access to what right now? | Yes, this is exactly what it shows |
| When was this permission granted? | No, the list keeps no history |
| Who granted it and who approved it? | No |
| For what stated reason? | No |
| Was a permission removed last year? | No, a removed permission never appears on the list |
The current list is a photograph; the record is the film. An audit wants the film: it wants to see how the permissions arrived at today's state. The only question a photograph answers is what exists right now, and that is the question an auditor cares about least.
The Six Fields a Record Must Carry
A permission change record should be able to answer, on its own, every question asked later:
- To whom. The user or role receiving the right. It should be parsed out of the script and stored as its own field; left as text inside the script it cannot be searched.
- What. The right itself: SELECT, EXECUTE, CONTROL, ALTER. Also a separate field.
- Where. Which server, database and object. The same right means different things in test and in production.
- Who asked. The person who opened the request, and a ticket number if there is one.
- Who approved. The approver, their role and the approval rule in force that day.
- Why. A written justification. If this field can be left empty, nobody will remember a year later.
Why separate fields rather than inside the script
Answering that the script is stored and the detail is inside it does not hold up in an audit. An auditor asks for a list such as every permission granted to user X last year. Unless the receiving principal and the granted privilege are parsed out of the script and stored as their own fields, answering that means reading hundreds of scripts by hand.
Temporary Access: Granted for a Day, Never Taken Back
The biggest source of privilege creep is not bad intent but temporary access that is never revoked. Access granted for a day to investigate an issue is not removed once the issue is solved, because nothing reminds anyone to remove it.
The practical answer is simple and not technical: the revoke script for temporary access is prepared at the moment it is granted. When the permission request is opened, the matching REVOKE statement is produced and tied to a date. Revoking stops being separate work and becomes part of the same request.
The second practical step is to mark permission changes as a never skippable rule. In an emergency many steps can be shortened; an operation that widens an access boundary should not be one of them. If a fix genuinely needs a permission, that permission enters the record and is revisited in the post event review.
Frequently Asked Questions
Does our identity management system not handle this?
Identity management handles which applications and groups a person belongs to, and it does that well. Database level rights usually sit outside it: a SELECT granted directly to a user, or membership added to a database role, does not appear in the identity system. The two complement each other; the change on the database side needs its own record.
Would managing through roles not make this easier to track?
It does, and it is the right approach. But the problem moves: now you must track which rights were added to the role and who was made a member of it. Role membership is itself a permission change and should carry the same six fields. Using roles does not remove the need for a record, it simplifies it.
Can a permission change be rolled back?
Technically yes: the counterpart of a GRANT is a REVOKE, and the counterpart of role membership is removing that membership. The point to watch is that revoking is itself a permission change. An unrecorded revoke is as problematic as an unrecorded grant; when someone's access is cut silently, that too must be explainable.
Where should we start?
By recording new permission changes. Trying to reconstruct the past is impossible in most organisations and only delays starting. From today, let every GRANT and REVOKE carry a request and an approval; a quarter later you will hold a record you can show an auditor. Reviewing the permissions that already exist is separate and longer work.
See the permission flow
We will walk the path a GRANT statement takes from request to approval, and from the record to its revoke script.
Book a Demo →