Database Security Policy Template: Access, Encryption and Monitoring Rules for Databases

Databases are breached through the same few gaps again and again: an instance reachable from the internet, an application connecting as a superuser, a service account password in source code, auditing that was never switched on, and backups nobody protected. This template turns those lessons into rules a database team can adopt and an auditor can test. It covers inventory and classification, network exposure, human privileged access, service accounts and application credentials, hardening, encryption, auditing, backups and decommissioning, for relational, NoSQL and managed cloud databases. It is written for CISOs, database platform owners and DBAs. The wider control set is explained in the Database Security Guide, and what to do when a database is breached in the Database Breach Response Playbook; this page is the policy.

How to use this template

• Replace text in square brackets, such as [Organisation], [database platform owner] and [90 days], with your own names and values.
• "Must" and "must not" are mandatory. "Should" is recommended practice where a documented exception may be justified.
• Put engine-specific settings (for example SQL Server, Oracle, PostgreSQL, MySQL, MongoDB parameters) in per-engine hardening standards based on the relevant CIS Benchmark, referenced from section 7. The policy stays engine-neutral.
• Apply the policy to managed cloud databases and data warehouses as well as self-hosted instances. Where the provider controls a setting, record how the requirement is met under the shared responsibility model.
• This policy sits beneath the [Information Security Policy] and alongside the Encryption Policy Template, Privileged Access Management Policy Template and Backup and Recovery Policy Template. Reference them rather than duplicating their rules.

1. Purpose

This policy sets the minimum security requirements for every database that stores or processes [Organisation] information, so that data is accessible only to authorised people and workloads, protected at rest and in transit, recorded in tamper-resistant audit logs, and recoverable after loss or destruction.

2. Scope

1. All database management systems and data stores operated by or for [Organisation], including relational databases, NoSQL and document stores, key-value caches, search clusters, data warehouses, vector databases and managed cloud database services, in production, staging, test and development.
2. All accounts that can connect to them: human administrators, developers, analysts, application service accounts, integration and ETL accounts, and AI agents or tools given database access.
3. Database copies, exports, snapshots, replicas and backups, which carry the classification of their source.

3. Roles and responsibilities

4. Inventory and classification

1. Every database instance must be recorded in [CMDB or data inventory] with its owner, environment, engine and version, hosting location, the highest classification of data it holds, and its network exposure.
2. Production data classified [Confidential] or above must not be copied to development or test environments unless it is masked or synthetic, or the target environment meets this policy in full.
3. Instances found by discovery scans that are not in the inventory must be assigned an owner within [5 business days] or shut down.

5. Network exposure

1. Databases must not be reachable from the internet. Listening ports (for example 1433 SQL Server, 1521 Oracle, 3306 MySQL, 5432 PostgreSQL, 27017 MongoDB, 6379 Redis) must be restricted by firewall or security group to the application hosts and administration paths that need them.
2. Databases must sit on an internal network segment separate from application and user networks.
3. Client applications on user devices or untrusted systems must not connect directly to a database; they must go through an API that enforces access control.
4. Web management tools for databases must require authentication, use HTTPS and be reachable only from administration networks.
5. All connections must be encrypted with TLS 1.2 or later, and clients must verify the server certificate. Unencrypted connections must be refused by the server.

6. Access control

6.1 Human and privileged access

1. Every connection must authenticate, including local connections. Default and anonymous accounts must be removed or disabled.
2. Administrators must use named personal accounts with the minimum role needed. Built-in superuser accounts (for example sa, root, SYS, postgres) must not be used for routine work; their credentials are held in [PAM solution] and every use is logged and reviewed.
3. Privileged database access must require multi-factor authentication, through the identity provider where the engine supports it or through [PAM solution] session brokering, and come from [privileged access workstations].
4. Standing administrative rights on production databases holding [Highly Confidential] data should be replaced with just-in-time access approved per task.
5. Access to production data by developers and analysts requires data owner approval and is limited to the schemas, views or rows needed. Restricted views, row-level and column-level permissions should be used for [Highly Confidential] data.
6. Access reviews: data owners review all accounts and roles on [Highly Confidential] databases [quarterly] and others [annually]. Accounts no longer needed are removed within [5 business days].

6.2 Service accounts and application credentials

1. Each application or service must have its own database account, used by nothing else. Separate accounts and databases are required for development, test and production.
2. Application accounts must hold only the permissions the application uses (often SELECT, INSERT, UPDATE and DELETE on named objects). They must not own the database, hold administrative roles or be able to change permissions or audit settings.
3. Application accounts must be restricted to connect from their application hosts, and must not be used for interactive logins by people.
4. Database credentials must be stored only in [approved secrets manager], never in source code, committed configuration, container images, tickets or chat. Where the platform supports it, workload identity or short-lived dynamic credentials should replace static passwords. See the Secrets Management Guide.
5. Static database passwords must be rotated at least [every 90 days], when a person with access leaves, and immediately on suspected exposure.
6. AI agents and automation tools must use their own scoped accounts, never a shared administrative credential, and must not hold DROP, TRUNCATE or DELETE rights on production data without a human approval step.
7. Every service account is registered with an owner, purpose and review date in the [service account inventory]. See the NHI Policy Template.

7. Hardening and patching

1. Each engine must be configured to a hardening standard derived from the current CIS Benchmark for that engine [Level 1 as a minimum] or vendor security baseline, and checked by automated scan at least [monthly].
2. Sample databases and unused features must be removed or disabled. Examples: SQL Server xp_cmdshell, CLR execution and the SQL Browser service unless required; the MySQL FILE privilege for application users.
3. Database services must run under a dedicated low-privilege operating system account.
4. Security patches must be applied within the timescales of the [Vulnerability Management Policy]: [14 days] for critical vulnerabilities on internet-facing or [Highly Confidential] systems.
5. Engines past vendor end of support must have a funded migration plan and compensating controls recorded as an exception.
6. Database links and linked servers must be avoided; where needed, they use a dedicated account with the minimum access.

8. Encryption

1. Data at rest in databases holding [Confidential] data or above must be encrypted using storage encryption or transparent data encryption, with keys managed under the [Cryptographic Key Management Policy].
2. Columns holding [Highly Confidential] fields (for example national identifiers, payment card numbers, health data) should use column-level or client-side encryption so that database administrators and a compromised database server cannot read them in clear.
3. Encryption keys and TDE certificates must be backed up separately from the data they protect, and key restore must be tested with the database restore in section 10.
4. The ability to change or supply encryption keys for database storage is a privileged action restricted to [named role].

9. Auditing and monitoring

1. Auditing must be enabled on every production database. Many engines record little or nothing until audit is configured, so each hardening standard must specify the audit policy explicitly.
2. At minimum, record: successful and failed logins; creation, change and deletion of accounts and roles; permission grants and revocations; changes to audit configuration; backup and restore operations; schema changes in production; and all activity by privileged accounts.
3. For [Highly Confidential] data, also record read access to the protected tables or columns, using database auditing or database activity monitoring.
4. Audit records must be forwarded to [SIEM] within [5 minutes] and stored where database administrators cannot alter or delete them. Retention: [12 months] online, [longer as regulation requires].
5. Audit settings must not capture plaintext passwords or full sensitive values where avoidable, and the audit store itself is access controlled.
6. [Security operations] must alert on at least: service account logins from new hosts or client tools; bursts of failed logins; privilege grants outside change windows; audit disabled or altered; and unusually large result sets or exports. See the Database Audit Log Detection Guide.

10. Backups, exports and decommissioning

1. Databases must be backed up according to the recovery point and recovery time objectives agreed with the data owner. Backups are encrypted, access controlled and include at least one copy that is immutable or offline.
2. Restores, including key and certificate restore, must be tested at least [twice a year] for [critical] databases and the result recorded.
3. Database exports and snapshots must be stored only in approved locations with the same classification controls, and must not be shared publicly.
4. When a database is decommissioned, its data, replicas, snapshots and backups are deleted or retained according to the [retention schedule], its accounts and credentials are revoked, and DNS and firewall entries are removed.

11. Exceptions, compliance and review

1. Exceptions are requested through [exception register] with the requirement affected, reason, compensating controls and an end date, approved by [CISO], and expire after no more than [12 months].
2. Compliance is checked by automated configuration scans, access reviews and [annual] internal audit. Breaches of this policy may lead to action under [disciplinary procedure].

Implementation guidance

Where the design choices come from

• Network, authentication and least privilege: the OWASP Database Security Cheat Sheet recommends isolating databases on internal segments, firewalling the port to specific hosts, refusing direct connections from thick clients, requiring authentication for all connections including local ones, one account per application, never using built-in superuser accounts, not making the application account the database owner, and keeping credentials out of source code. Sections 5 and 6 follow it.
• Hardening: the same cheat sheet points to CIS Benchmarks or vendor baselines, removing default accounts and sample databases, and running services under a low-privilege account, and lists SQL Server features to disable (xp_cmdshell, CLR execution, SQL Browser) and the MySQL FILE privilege.
• Audit defaults: engines differ sharply. SQL Server audits are created disabled, PostgreSQL's pgAudit logs nothing at its default setting, and some audit features depend on the edition, which is why section 9 requires an explicit audit policy per engine rather than trusting defaults (detail in the Database Audit Log Detection Guide).
• Encryption layers: transparent and storage encryption protect files, backups and media but not data read through a valid login; only column or client-side encryption keeps data from privileged database users. See the Database and Storage Encryption Guide.

Rollout

1. Build the inventory from cloud provider APIs, network scans for database ports and CMDB records; reconcile the three.
2. Close internet exposure first: it is the fastest, highest-value fix.
3. Move application credentials into the secrets manager and split shared accounts, one application at a time, testing each in staging and keeping the old credential valid until cut-over is confirmed (then revoke it).
4. Turn on the section 9 audit baseline in each engine, measure volume and storage impact in a pilot, then forward to the SIEM.
5. Run CIS-based configuration scans in report-only mode, fix findings through change control, then make the scan a release gate for new instances.
6. Bring privileged access under PAM with MFA, then remove standing administrative rights where just-in-time access is workable.

Measures

• Exposure: number of database instances reachable from the internet (target zero).
• Credential hygiene: percentage of application database credentials held in the secrets manager or replaced by workload identity, and number of shared service accounts.
• Audit coverage: percentage of production instances forwarding the section 9 baseline to the SIEM.
• Configuration compliance: average CIS Benchmark score per engine and count of critical findings older than [30 days].
• Restore success: percentage of critical databases with a successful tested restore in the last [6 months].

Failure patterns this policy is written to prevent

• Open databases: the DeepSeek database exposure was an open ClickHouse database that leaked chat logs and API secrets. Section 5 forbids internet exposure and section 4 finds unregistered instances.
• Over-privileged automation: in the PocketOS database deletion, an AI coding agent used an over-privileged platform token to wipe production. Section 6.2 gives agents scoped accounts and a human approval step for destructive rights.
• Applications as superuser: one SQL injection flaw then yields the whole instance. See the SQL Injection Prevention Guide.
• Audit on the same box: administrators, or attackers holding their accounts, can delete local logs. Section 9 requires off-host storage.
• Forgotten copies: unencrypted exports and test copies of production data are breached more easily than the source. Sections 4 and 10 carry classification to copies.

Framework mapping

Sources for the design choices

• OWASP: Database Security Cheat Sheet
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: Cybersecurity Framework 2.0
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements
• MITRE ATT&CK: T1505.001 SQL Stored Procedures

Related NHI Mgmt Group resources: Database Security Guide · Database Breach Response Playbook · Database Activity Monitoring · Service Account Security Guide