Contents
This article is not an official interpretation of the standard. It describes what four Annex A controls of ISO/IEC 27001:2022 mean in practice on the database side. What binds you is the text of the standard itself and the assessment of your certification body.
In most organisations holding an ISO 27001 certificate the controls are worked out in detail at the application and infrastructure layers. The database layer is usually waved through as part of infrastructure. When an auditor descends to that layer the picture is often the same: the control exists but the evidence does not.
Certified, But Is the Database in Scope
The Annex A controls do not name the database; they speak of information processing facilities and information systems. That generality is deliberate, but in practice it creates a gap: the organisation itself has to define how a control applies to the database. Where it does not, the control stops at the application layer.
Four controls have a direct counterpart on the database side. For each of them below, what the standard asks for and what that means in the database are written separately.
8.2 Privileged Access Rights
What the standard asks for: the allocation and use of privileged access rights should be restricted and managed. Rights should be identified, records of authorisation kept, and reviews carried out regularly.
What it means in the database: a database administrator account is privileged by definition and can reach all production data. The question is not to remove that access but to make its use recorded. Two kinds of evidence are needed: to whom the right was granted and why, and when that right was exercised.
The second is missing in most organisations. There is a permission list, but no answer to how many times and for what purpose that right was used last quarter. Tying access to production data to a request closes this gap: the right remains, but every use carries a reason and an approval.
8.15 Logging
What the standard asks for: logs recording activities, exceptions, faults and other relevant events should be produced, stored, protected and reviewed. Logging should reach well beyond user logins.
What it means in the database: the word protected is the most frequently skipped part of this control. For a record to count as a log it is not enough that it was produced; it must also be possible to show that it was not altered afterwards.
On the database side that has three practical conditions. The application account writing the record has insert only rights on that table. Rows are signed with a secret key and the key lives outside the database. A second copy of the record is held in a separate database. Together they stop whoever can reach the record from quietly correcting it.
8.32 Change Management
What the standard asks for: changes to information processing facilities and information systems should be subject to change management procedures. A change should be planned, assessed, authorised, tested and documented.
What it means in the database: the words assessed and authorised are decisive here. That a script was assessed before it ran asks for more than someone having looked at it: what the assessment rested on has to be written down.
In practice this means the script is parsed with the grammar of its database type, the rules it triggers are recorded, and the risk assessment rests on those findings. The approval steps then follow from that assessment. The answer to why one change went through two approvals and another through one becomes a written rule rather than a personal judgement.
The question of scope applies here too: if change management covers only planned schema changes, then emergency work and maintenance sit outside the control. The standard says changes, not changes that pass through the pipeline.
8.33 Test Information
What the standard asks for: test information should be appropriately selected, protected and managed. Protecting sensitive information in test environments covers measures such as access control and masking, and secure deletion after use.
What it means in the database: this control has two distinct faces and they should not be confused.
The first face is how the test environment itself is populated: is data copied from production anonymised on the way, or moved as it is. That is a data preparation job and is done with separate tooling.
The second face is data pulled from production one off: a query result taken to investigate a fault, a file sent to a team. In most organisations this path is not controlled at all, and it is usually where personal data leaves the organisation. Masking, access control and deletion after use are needed for this path too.
Do not confuse the two faces
Populating the test environment with anonymised data does not close the one off extraction path. When the data in test is not enough, the team goes back to production anyway. Unless both faces are handled separately, the control leaks through the path left open.
The Evidence the Auditor Will Ask For
| Control | The record that can serve as evidence |
|---|---|
| 8.2 | Request, approval and justification records for permission changes; every access to production data tied to a request |
| 8.15 | A signed audit trail, a second copy in a separate database and a check that verifies integrity independently |
| 8.32 | The rules the script triggered, the rationale of the risk assessment and the approval rule in force that day |
| 8.33 | Which columns were masked, the justification for anything sent unmasked and the retention period of the delivered file |
What these four rows have in common is that none of them is a policy document. A document shows that a control exists; a record shows that it operates. A certification audit asks for both, but findings almost always come from the second.
Frequently Asked Questions
We hold an ISO 27001 certificate. Is the database not automatically in scope?
The organisation defines its own scope and the certification body assesses that definition. The Annex A controls do not name the database; writing down how a control applies to it is the organisation's job. A control established at the application layer cannot be assumed to operate at the database layer as well.
Does what we did for data protection and banking regulation also count for ISO?
Largely yes, because all three ask for the same records: who, when, under what authority and for what stated reason. What differs is the presentation and the emphasis. Producing three views from one record therefore costs less than keeping three separate sets, and it removes the risk of the sets contradicting each other.
Do we have to remove our database administrator's production access?
The standard asks for privileged access to be restricted and managed, not eliminated. A database administrator needs that access to do their job. What is workable is to record the use rather than remove the right: the permission stays, every use carries a reason and can be reviewed.
How long before the audit should we start?
For record based controls there is no retroactive preparation; the auditor asks for a period's records. A quarter is the practical threshold: three months of produced records is enough to show the control genuinely operates. Preparation started two weeks before an audit produces documents only.
See the evidence in your own records
Let us walk through which record can serve as evidence for each of the four controls, using your own scenario.
Book a Demo →