How to Turn the DoD SQL Server STIG into a Practical DBA Checklist

# Summary Server is thorough but not optimized for quick, repeatable DBA reviews. This brief explains how to convert the STIG into a compact, usable checklist you can open, work through, and reuse. The goal is a checklist that answers what you're checking, why, how to verify it, what constitutes pass/fail, and what evidence to collect.

# What to capture for each STIG rule For each rule move beyond copying the STIG wording and capture specific, actionable fields:

• STIG ID and severity
• Requirement summary
• Concrete check steps you can run
• Fix steps or links to remediation guidance
• Instance or database scope
• Applicability flag (Does this apply to the target?)
• Current status (Pass, Open, Not Applicable, Not Reviewed)
• Evidence to record (logs, configs, screenshots)

These fields make the checklist a working document you can hand to another DBA and get a consistent assessment.

# Using the STIG Viewer to build and run checklists

1. 1Open STIG Viewer and create a new checklist for a SQL Server instance or database.
2. 2Add rules individually (search and pick specific rules) or add the full STIG.
3. 3Save the checklist with an intuitive name.
4. 4Open the checklist and annotate it for the instance/database under review.
5. 5Cycle rule statuses: Not Reviewed -> Pass (green) -> Open (red) -> Not Applicable.
6. 6Add findings details and comments in each rule's fields.
7. 7Export the completed checklist to HTML and print or save as PDF for records.

# Suggested checklist categories (practical DBA focus) Organize checks into categories that match routine DBA concerns and audits:

• Authentication: methods and policies for user sign-in
• Authorization: who has access and at what scope
• Accounts & Logins: SQL vs Windows accounts, disabled accounts
• Privileges: sysadmin, server roles, and database roles
• Auditing: login and security-related audit configuration
• Encryption: TDE, TLS, encryption at rest and in transit
• Network Security: ports, protocols, and exposure
• Configuration: server-level security settings
• Database Security: object ownership and permissions
• Service Accounts: identities used by SQL Server services
• Agent Security: jobs, proxies, and credentials
• Sensitive Data: presence and protection of PII and regulated data
• Monitoring: security event collection and alerting
• Documentation: exceptions, evidence, and remediation tracking

Group rules into these categories so a DBA can run focused sweeps instead of hunting through the entire STIG.

# Checklist as a collaborative tool The checklist should not be a fast pass to change production settings. Use it to:

• Document current state and gather evidence
• Assess whether a change is necessary and who must approve it
• Record exceptions when a requirement does not apply or cannot be met
• Apply remediation in a controlled manner and validate the result

This sequence helps teams avoid rushed changes and keeps a clear audit trail of decisions and evidence.

# Practical next steps

• Create a template document that contains the fields above and the category structure.

• Run one pilot assessment on a nonproduction instance to refine checks and evidence requirements.
• Share the checklist within your team and iterate based on feedback.