Database Controls: What an IS Auditor Tests
Anyone who can write to the tables can bypass every application control. That is why the database gets its own audit.
Every ledger balance an auditor relies on sits in a database. Application controls (validation, approvals, maker-checker) only protect data that enters through the application. Anyone who can write to the tables directly can bypass all of them, which is why the database layer gets its own audit.
DISA Module 4 treats the DBMS as part of software operations. In practice the work is three questions: who can change data outside the application, are those changes logged and reviewed, and can the database be recovered to a correct state after a failure?
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
Database Terms an Auditor Needs
- DBMS
- Database management system: the software (Oracle, SQL Server, SAP HANA, PostgreSQL) that stores data and controls how it is read and written.
- Database administrator (DBA)
- The person or team that installs, tunes, backs up and secures the database. Usually holds the most powerful access in the IT estate.
- Schema and data dictionary
- The schema is the structure (tables, fields, relationships); the data dictionary records it. Changes to either are program changes and need change control.
- Integrity constraints
- Rules enforced by the database itself: primary keys (no duplicate records), referential integrity (no invoice for a non-existent vendor), and field-level checks.
- ACID
- Atomicity, consistency, isolation, durability. A transaction posts completely or not at all, leaves data valid, is not disturbed by concurrent ones, and survives a crash once committed.
- Transaction log
- The database's record of every change. Used to roll back incomplete transactions and roll forward committed ones after a restore.
- View
- A stored query that shows users only selected rows or columns. A common way to restrict access without copying data.
Database Risks and the Controls That Answer Them
| Risk | Control to test |
|---|---|
| Direct updates to tables ("data fixes") bypass application controls | Data-fix requests approved like program changes; DBA activity logged and reviewed by someone outside the DBA team |
| Excess privileged access | Named DBA accounts, no shared default accounts in use, periodic review of who holds administrator and write rights |
| Logging switched off or editable by DBAs | Database audit logging enabled for privileged actions; logs sent to a system the DBA cannot alter |
| Duplicate or orphan records | Primary key and referential integrity constraints enabled, not disabled for performance |
| Loss of data after a crash | Backups plus transaction logs, with tested point-in-time recovery |
| Sensitive data exposed in test copies | Masking of personal and financial data when production is copied to test |
Quick practice on audit concepts. No signup.
A Worked Example: Core Banking Data Fixes
A bank's IT team runs back-end scripts each month to correct failed interest postings. Each fix is technically sound, but it changes customer balances without a maker-checker in the application. The auditor's tests: obtain the population of scripts run on production (from database logs, not from the IT team's list), match each to an approved request with business sign-off, and check that whoever reviewed the log was independent of whoever ran the script.
The same logic applies to a mid-size company on SAP: direct table edits through database tools or debug access in production need the same scrutiny as a journal entry posted without approval.
How the DISA Assessment Test Tests This
Expect scenario MCQs on a data integrity risk. Options often include "strong application controls" as a distractor. If the stem mentions direct database access, DBA privileges or back-end updates, application controls are irrelevant: the right answer is at the database layer (restricted access, logging, independent review). Also watch for rollback versus roll forward: rollback undoes uncommitted transactions; roll forward reapplies committed ones from the log after restoring a backup.
FAQs
What does an IS auditor check in a database audit?expand_more
Who holds privileged and write access, whether direct data changes are approved and logged, whether logs are reviewed independently, whether integrity constraints are enforced, and whether backups and transaction logs allow tested recovery.
Why is DBA access a risk?expand_more
A DBA can read and change any data and often the logs too, bypassing every application control. The usual answer is named accounts, logging to a place the DBA cannot change, and independent review.
What is referential integrity?expand_more
A database rule that a record cannot refer to something that does not exist, for example a purchase invoice pointing to a vendor code that is not in the vendor master.
What is the difference between rollback and roll forward?expand_more
Rollback reverses transactions that had not committed when a failure occurred. Roll forward reapplies committed transactions from the transaction log to a restored backup to bring it up to date.
Next steps
Take a full DISA mock testAssessment Test format, timed and scored.