Skip to main content
The goal of remediation is not merely to reduce the number of findings. Each decision should remove or consciously accept the underlying risk, preserve required SQL behavior, and leave enough evidence for another reviewer to understand the outcome.

​
Goal

Investigate, remediate, re-review, and document SQL findings so that each risk is removed or consciously accepted with evidence.

​
Prerequisites

A review ticket with findings to resolve, and access to modify and re-review the SQL.

​
Remediation loop

​
Work through a finding

1

Verify the trigger

Read the rule, SQL location, and related objects. Confirm the database version and workspace context.
2

Assess actual impact

Determine whether the issue affects correctness, performance, security, maintainability, or release safety.
3

Choose a disposition

Modify the SQL, correct incomplete context, fix ticket configuration, or request an authorized exception.
4

Validate the change

Test semantics and, where appropriate, performance so that results and data effects remain correct.
5

Run the review again

Reuse the same policy and workspace unless a deliberate revision is part of the change. Compare the new result with the original.
6

Record the outcome

Preserve the change, evidence, residual risk, owner, and related ticket or approval.

​
Common dispositions

​
Validate remediated SQL

Confirm at least the following:
  • the target database can parse the SQL;
  • query results or data-change semantics remain correct;
  • transaction, locking, and concurrency behavior is acceptable;
  • index or rewrite candidates provide value under representative conditions;
  • the original issue is gone and no new high-risk finding has appeared;
  • required testing, approval, deployment, and rollback controls are complete.
Do not deploy generated or recommended SQL without validation. DDL, wide-impact DML, locking-sensitive changes, and data repair must follow your organization’s database change process.

​
Accept a finding as an exception

When remediation is not appropriate, use the exception process in Manual Review and Approval: record the business rationale, impact, and compensating controls, and keep the exception to the narrowest scope. Do not weaken a global policy to accommodate one isolated case.

​
Remediate at scale

  • Prioritize by severity, system criticality, and execution frequency.
  • Group findings by rule to expose reusable fixes.
  • Change SQL in small batches with regression coverage.
  • Compare risk distribution and performance evidence before and after remediation.
  • Feed proven patterns back into engineering standards and review policies.

​
Expected Result

After remediation and re-review, the resolved findings no longer trigger, no new high-risk finding appears, and the outcome is recorded with evidence.

​
Next steps

For blocking issues, see Control High-Risk SQL. When a person must make the final disposition, continue to Manual Review and Approval.