Segregate Environments for Database Servers
Keep development and production database servers separate to ensure secure operations.
Plain language
This control is about making sure that the database servers used for development, testing, staging, and actual operational purposes are kept separate. It matters because mixing them up can lead to mistakes or data breaches, which can disrupt business operations or expose sensitive information.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Feb 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for database systemsSection
Database serversOfficial control statement
Database servers for development, testing, staging and production environments are segregated.
Why it matters
If dev/test/stage and production databases aren’t segregated, test activity can expose or alter production data, causing outages and data breaches.
Operational notes
Audit access and network rules to ensure dev/test/stage DBs cannot reach production, and enforce separate accounts, credentials and backups per environment.
Implementation tips
- IT team should create separate environments: Set up different database servers for development, testing, staging, and production environments. Ensure each is isolated by configuring networks and using separate physical or virtual servers.
- System administrators should manage access: Assign specific permissions so only developers can access the development server, while only operational staff can access the production server. Use strong passwords and change them regularly to maintain security.
- Managers should document server purposes: Clearly list the purpose and users of each server environment. Make this document available to all relevant staff to avoid confusion about which server should be used for what.
- IT support should monitor database environments: Regularly check server usage and performance. Use basic monitoring tools to identify any deviations or unauthorised access attempts and address any issues promptly.
- IT team should update security protocols: Conduct regular reviews of security measures on each server environment to ensure they comply with the latest security guidelines. Refer to resources from the Australian Cyber Security Centre for up-to-date advice.
Audit / evidence tips
- AskA network diagram: Request a diagram showing the separation of different environments GoodShows distinct separations with firewall details and access points
- AskAccess logs: Request logs of recent access attempts to each server environment GoodContains minimal cross-access between environments and logs of attempts blocked by permissions
- AskServer documentation: Request a document detailing each server's purpose and user lists GoodShows clearly defined roles and responsibilities associated with each server
- AskA monitoring report: Request a report on recent monitoring activities for each environment GoodIncludes records of regular checks and actions taken to address any anomalies
- AskSecurity review records: Request documentation of the last security audit or review GoodDetails review outcomes, changes implemented, and future review dates
Cross-framework mappings
How ISM-1273 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 8.31 | Annex A 8.31 requires development, testing and production environments to be separated and secured | |
| handshake Supports (1) expand_less | ||
| Annex A 8.33 | Annex A 8.33 requires selection and protection of test information to prevent leakage of sensitive data | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.