Database structures, query logic, integrity controls, and security.
This chapter introduces the database concepts needed to understand how systems store and control information. The emphasis is on structure, access, and integrity rather than deep technical administration.
Database questions become assurance-relevant when structure or access affects completeness, accuracy, authorization, and retrievability. The candidate does not need to administer a database, but does need to understand how poorly designed schemas, weak access rules, or unreliable queries can distort evidence.
| Database issue | Assurance concern | Common ISC trap |
|---|---|---|
| Schema and normalization | Structure affects duplication, consistency, and update reliability. | Assuming stored data is reliable because it is in a database. |
| Query logic | Filters, joins, operators, and aggregation determine what data is retrieved. | Accepting query output without checking whether the query captured the right population. |
| Data dictionary | Definitions and constraints support consistent interpretation and validation. | Ignoring inconsistent field definitions across systems. |
| User access | Privileges determine who can read, change, export, or administer data. | Reviewing application access but missing direct database privileges. |
| Step | ISC question to ask | Control implication |
|---|---|---|
| 1. Identify the data model | What tables, fields, relationships, and keys define the stored information? | Weak structure can create duplicate, incomplete, or inconsistent records. |
| 2. Check definitions and constraints | Are required fields, allowed values, and referential rules documented and enforced? | Integrity controls reduce the chance that invalid data becomes audit evidence. |
| 3. Evaluate access paths | Who can query, change, export, administer, or bypass application controls? | Direct database access can defeat otherwise strong application-level permissions. |
| 4. Review change and backup controls | Are schema changes, migrations, backups, and restorations controlled? | Data reliability depends on controlled change as well as day-to-day access. |
| 5. Assess query reliability | Does the query capture the right population, period, join logic, and filters? | Reliable source data can still produce unreliable evidence if retrieved incorrectly. |
| Checkpoint | Ask before relying on database output | Evidence risk |
|---|---|---|
| Population completeness | Did the query include the full table, period, status, and business unit needed for the test? | Missing records can make a control or substantive test appear stronger than it is. |
| Join accuracy | Are tables connected by the correct keys, and are unmatched records handled correctly? | Incorrect joins can duplicate, omit, or misclassify transactions. |
| Field meaning | Does the data dictionary define the field, allowed values, and update source? | Similar field names can represent different business events across systems. |
| Privilege review | Who can create, alter, delete, export, or directly update database records? | Powerful direct access can bypass application controls and audit trails. |
| Change traceability | Are schema changes, scripts, migrations, and backup restorations approved and logged? | Uncontrolled changes can weaken integrity even when ordinary access looks restricted. |