Audit-Ready by Design: Preparing Your Database Controls for Singapore's Year-End Audit Season
Internal audit, external auditors and MAS inspection teams all ask the same things as 2026 closes out. What changed in your production systems? Who approved it? Was it tested? And can you prove it?
Application code is the easy part for most teams, because pipelines, pull requests and release tickets leave a clear trail. Database changes rarely do. Different people make them through different tools, and some skip the release process altogether. When the audit request lands, teams end up piecing a year of history together from tickets, logs and spreadsheets.
We wrote last year about how smarter database controls help Singapore FSIs meet MAS expectations. This post updates that for audit season, using our partner Liquibase's audit-readiness guidance and the changes MAS proposed in 2026 to its Technology Risk Management Notices.
Why database change is the audit blind spot
Databases change often and the evidence rarely keeps up. Liquibase's 2026 State of Database Change Governance Report found that 95% of organisations face multiple audits each year, yet only 32% can produce audit-ready database change history.
MAS has spotted the same weakness. Its June 2026 Consultation Paper on Proposed Amendments to the Notices on Technology Risk Management observed that a significant number of IT incidents in FIs were attributed to poor change management. The consultation closed on 31 July 2026 and proposes that FIs must:
Implement effective controls to prevent unauthorised system changes
Assess the risk of every proposed change before implementation, including its impact on upstream and downstream systems
Test all changes to critical systems before they reach production, with effective change recovery measures in place
Continuously monitor critical systems, with defined alert thresholds and response procedures
Maintain an immutable or offline backup of data crucial to their business services
Count partial and intermittent disruptions toward the existing limit of four hours' unscheduled downtime per critical system in any 12-month period
MAS proposes that the revised Notices take effect 12 months after they are finalised. This year's audit cycle is a sensible time to close database change gaps, ahead of them becoming formal requirements.
Auditors are also starting to ask a newer question. AI agents and AI-assisted tools can now generate and apply database changes, and the consultation asks FIs to consider AI risks in their IT risk assessments. If an agent changed a production schema, could you show it was held to the same policies as a human developer?
What auditors will ask for, and the database evidence that answers it
Auditors want proof that the policy was followed on every change, not a policy document. The table below maps the MAS expectations most relevant to databases to the evidence you should be able to produce on request.
MAS expectation | What the auditor asks | Database evidence that answers it |
Prevent unauthorised changes | Show me every schema change to this critical system and who approved it | A single change record per deployment: author, approver, ticket, timestamp, target environment |
Segregation of duties | Who wrote this change, and who deployed it? | Role-based access and enforced approval workflows, with the two identities recorded separately |
Pre-implementation risk assessment | How did you assess the impact before it went live? | Automated policy checks run on every change, with pass/fail outcomes stored |
Testing before production | Prove this change was tested before production | The same versioned change shown promoting through dev, test and UAT before production |
Change recovery | If this change had failed, how would you have recovered? | A pre-validated rollback for each change and a record of any rollback executed |
Continuous monitoring | How do you detect changes made outside the process? | Drift detection reports comparing environments against the approved change history |
Incident evidence | What changed in the hours before this incident? | A tamper-evident, time-ordered history of database changes across every environment |
AI and third-party risk | Which changes came from AI agents or vendors, and were they governed? | Changes attributed by source, with the same policy outcomes recorded for agents and humans |
Data protection (PDPA) | Is customer data exposed in non-production environments? | Records of test data masking applied consistently across test environments |
Your year-end database audit readiness checklist
Run through these questions before the auditors do. Any answer along the lines of "we'd need a few days to pull that together" marks a gap.
☐ Can we list every database change made to critical systems in 2026, across every team and database platform?
☐ Does each change show who authored it, who approved it, and who deployed it?
☐ Can we prove each change was tested in lower environments before production?
☐ Do we have evidence that policy checks ran on every deployment, including the results?
☐ Can we detect and explain schema drift or out-of-process changes, including emergency fixes?
☐ Is our change history tamper-evident, or could it be edited after the fact?
☐ Are primary and disaster recovery environments on the same schema version?
☐ Can we distinguish changes made by AI agents or third parties from those made by our own developers?
☐ Is sensitive data masked in every non-production environment?
☐ Could we produce all of the above as a report in minutes, not weeks?
From audit scramble to always-on evidence: how BTP Icon and Liquibase help
Audit season comes once a year, but evidence should be collected all year round. BTP Icon implements Liquibase Secure for Singapore and Southeast Asian FSIs so that evidence is captured as each change happens rather than reconstructed when the auditor asks. It works in three parts.
See every change. Liquibase Change Intelligence records who made each database change, what it was, where it went and when, across every team and more than 70 supported database platforms. Developers, DBAs, vendors and AI agents all land in the same record, and deployment status is visible in every environment.
Catch problems early. Policy checks run on every deployment and the outcomes are recorded. Risky changes are blocked before they reach production, and drift or out-of-process changes show up in one view, so they get fixed at the time and not in the audit room. That maps to MAS's proposed requirements for pre-implementation risk assessment and continuous monitoring.
Produce the evidence. The audit history is centralised and tamper-evident, with full execution context, so audit-ready reports take minutes to generate. AI-driven analysis explains each finding and points to the fix.
BTP Icon's test data management capabilities sit alongside Liquibase and mask sensitive data consistently across non-production environments. That supports PDPA obligations and gives teams realistic data for testing changes before they reach production.
Our local team brings the MAS context, mapping your controls to the TRM Guidelines and Notices and building the evidence packs your auditors and regulators expect, with approval workflows set up to match your governance structure.
Get audit-ready before the year closes
The audit window is short, and MAS is clearly heading towards tighter change controls, continuous monitoring and evidence for every change to critical systems. FIs that build that evidence into database delivery now will walk into this audit season, and the next, with answers ready.
To get started:
Book an Audit Readiness Assessment with BTP Icon and Liquibase to find your biggest database governance gaps and get a prioritised plan.
Download the Audit Readiness Checklist from Liquibase.
Read The Audit-Ready Database Playbook for governance, evidence collection and audit prep in one guide.
Talk to our team about mapping your governance controls.