A database transaction is a unit of database work treated as a single logical operation. It groups one or more reads and writes so they either all succeed or all fail, using commit and rollback behaviour to preserve consistency when concurrent access or failures occur.
What Database Transactions Do
Database transactions are the core mechanism that lets a database treat several reads and writes as one logical unit. They are designed to preserve consistency when multiple users, services, or processes touch the same data at once, or when a failure interrupts work before it is complete.
That single-unit behaviour matters because transactional systems are not just about speed, they are about correctness. Without a transaction boundary, partial writes can leave records out of sync, create orphaned references, or produce outcomes that are hard to detect until much later.
Commit, Rollback, and Isolation
The commit step makes a transaction's changes durable and visible to other sessions. The rollback step discards all changes made inside the transaction so the database returns to its prior state. Together, they provide the all-or-nothing behaviour that makes transactional systems reliable under failure.
Isolation controls what one transaction can see while another is still in progress. That is why databases can avoid many concurrency problems, such as dirty reads, while still allowing high levels of parallel activity. The exact isolation model shapes the trade-off between consistency, correctness, and throughput.
Why Transactions Matter for Data Integrity
Transactions are the safeguard that keeps related database changes aligned. A payment record, inventory update, and ledger entry often need to succeed together, or not at all. If one update is applied without the others, the application can end up reporting a state that never truly existed.
They also reduce the operational burden of recovery. Instead of trying to reason about every possible halfway state after a crash or timeout, the system can rely on the database to finish or abandon the unit of work cleanly. That makes downstream application logic simpler and less error-prone.
Transactional Design in Applications
Good transactional design means keeping the transaction scope as small as possible while still protecting the business operation being performed. Long-running transactions hold locks longer, increase contention, and can slow unrelated work in busy systems.
Applications also need to decide where the transaction boundary belongs. A boundary that is too narrow can expose partial updates, while one that is too broad can make failures expensive and concurrency poor. In practice, the boundary should match the smallest business action that must succeed or fail together.
Risk and Threat Considerations
Transactions become a security and reliability issue when integrity depends on them and an application uses them poorly. The main risk is inconsistent state, where partial commits, stalled rollbacks, or weak isolation create records that can be manipulated, duplicated, or left in a misleading condition.
Failure mechanism: Attackers or faulty code can exploit long-running operations, locking behaviour, or incomplete commit handling to cause denial of service, race conditions, or integrity drift across related records.
Impact: The result can be corrupted business data, incorrect authorisation decisions, broken audit trails, and recovery work that is harder because the database state no longer reflects a single trustworthy outcome.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-4 — Information in Shared System Resources | Transactions help preserve shared database integrity under concurrent access. |
| SI-7 — Software, Firmware, and Information Integrity | Transactional correctness supports detection and prevention of integrity corruption. | |
| Recommendation — Apply SC-4 to protect shared database resources from cross-session integrity loss. Use SI-7 to detect and block unintended data-state corruption in database workflows. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Transaction behaviour depends on secure database and application configuration. |
| Recommendation — Harden database and application settings so transactional controls behave predictably. | ||
| ISO/IEC 27001:2022 | A.8.13 — Information backup | Rollback and recovery both depend on reliable restore and recovery capability. |
| Recommendation — Align backup and recovery arrangements with transactional recovery needs. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | Transactional systems rely on protected database traffic to preserve consistency and integrity. |
| Recommendation — Protect database traffic to prevent tampering with transactional data exchanges. | ||
Practitioner Guidance
What to watch for: Treat transaction design as part of application correctness, not just a database detail. Watch for oversized transaction scopes, error paths that skip rollback, and logic that assumes isolation stronger than the database actually provides.
Practitioner note: Review transactional boundaries around the business operation, not around every individual query. The goal is to make the smallest reliable unit of work match the real-world action the system is trying to complete.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org