The Database Layer in Your Authorization: A Roadmap for ISSMs and System Owners

Database findings are among the most predictable in any federal assessment. Weak audit logging, stale privileged accounts, unencrypted data at rest, default configurations, missed patches and unsupported versions show up cycle after cycle. Each lands on the ISSM as a POA&M item, and each is the product of a database tier nobody was resourced to administer.

This roadmap is for the ISSM, ISSO or system owner who has to plan database administration and defend the database layer to an assessor and an Authorizing Official.

The Requirements That Apply

The End-of-Support Dates

Unsupported database software is an automatic, recurring finding. The dates that matter now:

• PostgreSQL 13: community support ended November 2025.
• SQL Server 2016: extended support ended July 14, 2026.
• PostgreSQL 14: community support ends November 2026.
• Windows Server 2016: extended support ends January 12, 2027.

For each affected instance, the plan should record one of three outcomes: upgrade, paid extended security updates with a retirement date, or migration. An instance with no recorded outcome is a finding waiting to happen. Paid extended updates buy time but not a solution; each one should carry a retirement or upgrade date that the system owner has agreed to, so the extended-support bill does not quietly become permanent.

Controls and the Artifacts That Evidence Them

The CP-4 evidence is the one most often missing. A backup log shows a job ran; a restore-test report shows the data can actually be recovered, how long it took, and what point it recovered to. Assessors increasingly ask for the second, and a system owner who has seen a measured recovery time can make a far better case to the AO than one who has only seen a green backup dashboard.

What Stays With the Government

Three decisions belong to the agency, and the plan should name who makes each:

1. Assessment and authorization. STIG checklists produced by the database team are self-assessment artifacts. The security control assessor draws the conclusions, and the Authorizing Official decides. A database contractor should never assess its own work.
2. Residual risk. When an instance cannot be upgraded on time, the extended-support plan or compensating control and the remaining risk go to the AO in writing.
3. Recovery objectives. Recovery time and recovery point objectives come from the business impact analysis and the system owner, not from the contractor.

Personnel Requirements

Privileged database access carries its own qualification requirements, and they should be in the solicitation, not discovered at onboarding:

• DoD systems: qualification under DoD 8140 for the Database Administrator work role, typically including Security+ or an equivalent baseline certification, and an investigation appropriate to the position.
• Civilian systems: a Public Trust investigation at the tier the agency requires, plus any agency-specific suitability adjudication.
• Coverage: a named, cross-trained second person, so leave and turnover do not leave the estate without an administrator.

Investigations and account provisioning routinely take two to eight weeks or more. The plan should treat access as a dated milestone.

Managed Cloud Databases

Moving a database to Amazon RDS, Aurora, Azure SQL or another managed service shifts some controls to the provider, and its FedRAMP certification covers that offering. It does not cover the agency's system. The customer-responsibility matrix for the service lists what remains with the agency, typically patch windows and version opt-ins, parameter and configuration groups, database accounts and roles, backup retention and restore testing, encryption keys, audit settings and log export. Those controls still need an owner, and their evidence still belongs in the authorization record. The inheritance should be documented control by control, so the assessor can see which parts the provider covers and which the agency implements.

Questions to Ask Before Buying Support

1. How many database instances are in scope, on which platforms, and which are past end of support?
2. When was each mission-critical database last restored, and is the result documented?
3. Which database findings are open on the POA&M today, and how old are they?
4. Who holds privileged database access now, and when were those accounts last reviewed?
5. What happens operationally if the current database administrator is out for two weeks?
6. Is a migration or re-platforming planned in the next 18 months? If so, the database work should be coordinated with it.

The answers size the work and set the order. An agency that cannot answer the second question should start with restore tests.

Contract Terms That Hold

A database support contract protects the schedule and the evidence by making dependencies explicit:

• Instance inventory as an appendix. Additions go through a change order rather than being absorbed.
• Baseline first. A written baseline and findings memo at transition-in, before any recovery commitments.
• Access as a government milestone. The schedule starts when access is granted.
• Restore-test cadence. At least quarterly for mission-critical databases, with measured results in the report.
• Defined ticket types. Data extracts, reports and application changes are separate work.
• Defined support hours. After-hours expectations written down rather than assumed.
• Transition-out committed. Runbooks, credential handoff and a final baseline, in the contract from day one.
• Firm fixed price for a stabilization sprint and for monthly support against the named inventory.

For civilian agencies tracking BOD 26-04, the database tier usually holds part of the vulnerability backlog. The cost side of closing that backlog (opens in a new tab) belongs in the same budget conversation as database support.

Sequencing the Work

A practical order for a program office: inventory every database instance and record its support status; decide an outcome for each end-of-support instance; commission a stabilization sprint that baselines the estate, brings patches current and runs the first restore tests; then move to monthly support with a regular evidence cycle. Database patches move through the same tested remediation waves (opens in a new tab) as the rest of the system, so coordinate the two rather than running parallel change processes.

Avalon's Network Database Administration service brings the database tier to a documented, STIG-aligned configuration, runs restore tests with measured recovery times, and produces the evidence your ISSO files, with named personnel matched to your platforms and access requirements.