Skip to main content
High-risk SQL controls prevent significant, unverified database risk from moving silently into a release. Effective control combines policy-based detection with human judgment, representative testing, and the organization’s change-management process.
Blocking, exception, approval, and quality-gate features depend on PawSQL edition, licensing, and integration configuration. Where an in-product workflow is unavailable, use the PawSQL review report as evidence in an external ticketing or CI/CD gate.

​
Goal

Control high-risk database changes by combining policy-based detection with human judgment, representative testing, and the organization’s change-management process.

​
Prerequisites

A production-ready review policy with blocking or high severity assigned to critical rules, and an established change-management and exception process.

​
Typical risk categories

Your organization’s review policies define which cases are high risk.
1

Detect automatically

Use a production-ready policy and assign blocking or high severity to critical rules.
2

Establish the operating context

Confirm the target environment, affected objects, data volume, execution duration, and maintenance window.
3

Reduce risk first

Correct the SQL, split the operation, narrow predicates, or choose a safer execution approach.
4

Validate under controlled conditions

Test semantics, plans, runtime, locking behavior, stop conditions, and rollback readiness.
5

Handle unavoidable exceptions

Submit the rationale, compensating controls, and expiration date for authorized review.
6

Release with evidence

Continue only after the gate is satisfied, and retain the review, approval, and execution record.

​
Suggested gate decisions

​
Handle exceptions

When a risk cannot be removed, use the exception process in Manual Review and Approval: submit the rationale, compensating controls, and an expiration date for authorized review, and bind the exception to a specific SQL statement, rule, project, environment, and validity period.
Urgency does not remove the need for risk assessment. An emergency change should still retain the minimum necessary review, authorization, backup, monitoring, and rollback controls.

​
Integrate with CI/CD or ticketing

An automated workflow can evaluate ticket status, highest severity, unresolved finding counts, or a report outcome. Design the integration to:
  • pin or record the review-policy revision;
  • define safe behavior for failures, timeouts, and incomplete analysis;
  • prevent unauthorized users from bypassing the gate;
  • retain the ticket link, report, and pipeline evidence;
  • provide a controlled manual fallback for service incidents.
See SQL Quality Gate and SQL Quality Gate for CI/CD for related patterns.

​
Expected Result

Each high-risk change is detected, remediated or covered by a time-bounded exception, and released only after the gate is satisfied with retained evidence.

​
Verification

Confirm that no unresolved blocking finding remains and that the gate decision matches the recommended outcome before proceeding.

​
Next step

When an authorized person must decide whether the change can proceed, see Manual Review and Approval.