Frameworks ask you to demonstrate that a control operates. SQL Change Guard is a Database Operations Governance platform that governs database changes and production data access, and it produces that record out of the work itself. The tables below show which record answers each expectation, and teams preparing for an audit can use them directly as a checklist.
SQL Change Guard is not certified against any standard and we do not claim it is. Compliance comes from your own scope, policies and audit. The only thing software can do is produce the record that shows a control operates. That is all this page describes: which record answers which expectation.
ISO, COBIT, ITIL and local regulation use different vocabularies, but at the database layer they all arrive at the same four questions. Most organisations prepare separately for each framework, when producing the answer to these four once serves all of them.
Even with a certificate, the database layer being in scope is something you have to demonstrate separately. The four controls below are the ones that most often produce findings at the database layer.
| Control | Expectation | Record produced |
|---|---|---|
| 8.2 Privileged access rights |
Elevated permissions must be limited, allocated and monitored, and their use reviewed. | Permission change records, the permission based access table, privileged operations tied to a request record and the audit trail of role assignments. |
| 8.15 Logging |
Activity records must be produced, retained, protected and reviewed. | An audit trail signed with a keyed digest chain, a full row copy in a separate database and the chain verification result. That the record is protected can also be demonstrated on the auditor's own machine: a signed evidence package and a comparison against an anchor delivered earlier (how). |
| 8.32 Change management |
Changes to information processing facilities must follow a controlled procedure. | The request, the rule assessment, the risk band, the approval chain, the execution record and the digest comparison, including rejected requests. |
| 8.33 Test information |
Test information must be selected with care, protected and controlled. | The request record for data leaving production, the masking decision and the download reason. Limit: the product does not govern bulk copying between environments; it records people taking data out of production. |
In depth: ISO 27001 and the database: what four controls mean.
Both frameworks are written to be technology neutral, so neither addresses the database separately. The expectation covers it, but the process was usually designed around an application release, and that is where the break starts.
| Expectation | Record produced |
|---|---|
| BAI06 Changes are logged, categorised, assessed for impact and risk, authorised and planned. | A rule based risk band on every request with the list of findings that fired. Because the assessment is written rules rather than human judgement, the same script always gets the same result and reproducibility can be demonstrated. |
| BAI06.03 A system tracks and reports status, and rejected changes are documented as well. | A rejection is written into the request's own history with its reason and appears in reports. This is the evidence organisations most often lack: a record showing only approvals does not demonstrate that the control filters anything. |
| Emergency changes follow a controlled route and are verified afterwards as appropriately assessed (COBIT); a post implementation review is carried out (ITIL). | An emergency record is opened with an incident number and a stated reason, and the post hoc review stays on an open list until closed. Whether the emergency route has become a shortcut becomes visible as a number. |
| An ITIL 4 change authority can be a person, a team or an automated mechanism, and authority should be distributed by risk. | Approval policies are defined per risk band: a low band passes with one approval or pre authorisation, a high band requires multiple approvals and a stated reason. The board sees only work that genuinely needs assessment. |
| MEA Continuous monitoring of internal control and of compliance with external requirements. | Control exceptions are visible on the dashboard during the day and thirty one built in reports across five groups can be run on a schedule. Evidence does not have to be assembled by hand once a year. |
In depth: COBIT BAI06 and ITIL 4: five break points at the database layer.
At the database layer, personal data risk concentrates in reads rather than changes. Even in organisations with mature change management, extracting data from production usually goes ungoverned.
| Principle | Record produced |
|---|---|
| Record of the processing activity | Every request that pulls data from production: who asked, on what stated basis, from which server, which columns, who downloaded the result and why. |
| Data minimisation | Sensitive columns are masked by default. Unmasked access is a separate decision requiring a reason and an extra approval, and a masked only regime can be enforced per server. |
| Data security measures | The result is delivered as an encrypted package, the package password is not emailed, and access traces are signed into the audit trail. Detail: security architecture. |
| Joint responsibility with a processor | Vendors and consultants work through the request flow rather than holding a standing server password. What each of them did stays recorded on your side. |
In depth: preparing the database side for a data protection audit and real data in test environments.
What stalls an audit is not missing records but records that do not answer the question. When the four questions and four kinds of evidence (request, assessment, approval, execution) come together in one file, sample review takes minutes.
The database side of a regulatory audit: four questions, four kinds of evidence
Every account, including administrative and vendor accounts, is expected to carry a unique ID for traceability. At the database layer this is often breached because operations appear under shared service accounts. The answer is not splitting accounts but separating connection identity from action identity.
The evidence file for a request is exported as one package. It contains a readable summary document, machine processable data and a digest that seals the package. An auditor can verify it independently and show that the file is as it was produced, without needing the product.
Exporting evidence is itself a separate permission and is written to the audit trail: who took the evidence, when and for which request is recorded.
The hardest question in an audit is judging a past decision against the rule of that day. The rule set is frozen into the record at the moment the request is opened. When policies change later, the past decision is still read in its own context rather than looking wrong through no fault of its own.
Bring the questions you were asked in your last audit; we will show live where the evidence for each one comes from.
Request a demo →Related pages: security architecture, audit trail and evidence, what Database Operations Governance is.