BUILDING A BULLETPROOF GRC PROGRAM — Part 5 of 8: Custom Controls, Release Gates & ServiceNow…

Custom Controls: Beyond The Baseline

The baseline (Part 4) gives you the minimum. But some assets face unique risks that the standard baseline does not address. That is where custom controls come in — additional requirements layered on top of the baseline for specific risk scenarios.

When Custom Controls Are Needed

• Asset handles payment card data → add PCI-specific controls (tokenization, CDE isolation, quarterly ASV scans)

• Asset processes health data → add HIPAA-specific controls (PHI encryption, access logging, minimum necessary)

• Asset is public-facing with high user volume → add enhanced WAF rules, DDoS protection, bot detection

• Architecture uses unusual patterns (WebSocket, gRPC, serverless) → add technology-specific controls

• Threat model reveals unique attack surfaces → add targeted mitigations for identified scenarios

• A security incident exposed a gap → new control added to prevent recurrence

• New regulation applies specifically to this asset → add regulatory-specific requirements

How Custom Controls Are Added

The process follows the same governance workflow as everything else:

• TRIGGER — A threat model, regulation, incident, or architecture review identifies a risk the baseline does not cover

• PROPOSAL — Security architect or tech lead proposes a specific custom control with justification

• APPROVAL — Security lead or CISO reviews and approves (ensuring it is proportionate to the risk)

• ASSIGNMENT — Control added to the asset's profile in ServiceNow. Owner assigned. Due date set.

• TRACKING — Same lifecycle as baseline controls: evidence, monitoring, escalation if overdue

• Custom controls are tagged separately from baseline controls in ServiceNow, so dashboards show both:

• Baseline completion: how well this asset meets the universal minimum

• Custom compliance: how well it meets its unique additional requirements

• Total compliance: the complete picture

Example: Payment Service (App-002)

This API service has the standard 7-control API baseline plus 5 custom controls because it processes payment card data:

• Standard baseline controls (all complete):

• BL-API-01 through BL-API-07 — SAST, SCA, rate limiting, OAuth2, schema validation, no sensitive logging, mTLS

• Custom controls (added after threat model and PCI scoping):

• CUS-PAY-01: PCI tokenization for card data

• Rationale: Asset handles card numbers. PCI-DSS requires that PANs are tokenized or encrypted.

• Framework: PCI-DSS 3.4

• CUS-PAY-02: Network segmentation (Cardholder Data Environment isolation)

• Rationale: The payment processing network must be isolated from general corporate network.

• Framework: PCI-DSS 1.3

• CUS-PAY-03: Quarterly Approved Scanning Vendor (ASV) external scan

• Rationale: PCI-DSS 11.2 mandates quarterly external vulnerability scanning by an approved vendor.

• Framework: PCI-DSS 11.2

• CUS-PAY-04: Transaction anomaly detection

• Rationale: Fraud risk identified in threat model. Unusual transaction patterns must generate alerts.

• Framework: Risk-based (from threat model)

• CUS-PAY-05: Field-level encryption for Primary Account Number (PAN)

• Rationale: Defense-in-depth. If the database is breached, card data remains encrypted at the field level.

• Framework: PCI-DSS 3.4, threat model recommendation

• Total controls for this asset: 12 (7 baseline + 5 custom)

• Current status:

• Baseline: 7/7 complete (100%)

• Custom: 3/5 complete (60%)

• Total: 10/12 (83%)

• Blocking: CUS-PAY-03 (ASV scan) is P1 and incomplete — deployment blocked

Who Adds Custom Controls

• Initial threat model during design phase → proposed by Security Architect, approved by CISO

• New regulation applies to asset → proposed by GRC Team, approved by Compliance Officer

• Incident reveals gap → proposed by Incident Responder, approved by Risk Owner

• Penetration test finding → proposed by Security Engineer, approved by Control Owner

• Architecture change introduces new risk → raised by Tech Lead, validated by Security Team

Release Gates: Servicenow Sign-Off

This is the most powerful enforcement mechanism in the entire GRC program: your CI/CD pipeline cannot deploy to production without ServiceNow confirming that all required controls are satisfied.

How The Gate Works

• Step 1: Developer merges code → CI builds artifact → pipeline reaches deployment stage

• Step 2: Pipeline makes an API call to ServiceNow:

• "Asset APP-002 is requesting production deployment. Commit SHA: abc123. All CI scans passed."

• Step 3: ServiceNow evaluates the compliance status for this specific asset:

• Are all P1 baseline controls in "Effective" status?

• Are all P1 custom controls in "Effective" status?

• Are there zero critical open vulnerabilities for this asset?

• Are there no blocking audit findings?

• If any control is non-compliant, is there a valid (approved, non-expired) exception?

• Is there an approved change request for this deployment?

• Is the current time outside any change freeze window?

• Step 4: ServiceNow returns a response:

• If ALL checks pass → APPROVED (pipeline proceeds to deploy)

• If ANY P1 check fails → BLOCKED with specific reason

• The developer sees exactly what is blocking them and what needs to be resolved.

Gate Strictness By Asset Criticality

Not all assets require the same level of approval:

• CRITICAL assets (payments, customer data, authentication):

• 100% P1 controls must be passing

• Zero critical vulnerabilities

• CISO or security lead explicit approval

• Change Advisory Board (CAB) review

• Rollback plan documented

• HIGH assets (core services, internal-facing critical):

• 100% P1 controls must be passing

• Zero critical vulnerabilities

• Security lead approval

• Standard change process

• MEDIUM assets (internal tools, dashboards):

• 100% P1 controls must be passing

• Zero critical vulnerabilities

• Auto-approved if all conditions are met (no human in the loop)

• LOW assets (documentation sites, internal utilities):

• SAST and SCA passing

• Auto-approved

Pipeline Implementation Example

In a GitHub Actions workflow, the gate is a step that calls ServiceNow:

• name: ServiceNow Deployment Gate

• action: Makes HTTPS POST to ServiceNow change management API

• sends: asset_id, change_type, deployment_ref (commit SHA), scan_results_passed (boolean)

• receives: state (approved or blocked), reason (if blocked), change_number (if approved)

• If state is not "approved":

• Pipeline prints: "BLOCKED — Reason: [specific control or finding]"

• Pipeline exits with failure code

• Deployment does not proceed

• If state is "approved":

• Pipeline prints: "APPROVED — Change number: CHG0012345"

• Deployment proceeds normally

This is fully automated. No Slack messages, no manual approvals for routine deploys. The gate checks compliance status programmatically.

Handling Blocked Releases

When the gate blocks a deployment, the team has three clear options:

• OPTION 1: Complete the control (preferred path)

• Fix the gap. Implement the missing control. Provide evidence. Re-trigger the pipeline.

• The gate re-evaluates and passes. This is the normal, expected resolution.

• OPTION 2: Request a policy exception

• Submit an exception request in ServiceNow with business justification.

• Expedited approval workflow: Security Lead + Engineering Director.

• If approved:

• Exception is time-bound (example: 14 days)

• Conditions are documented (what must be done within the exception window)

• Risk acceptance is formally recorded with approver name

• Pipeline receives override authorization

• ServiceNow creates a follow-up task with a hard deadline

• If not approved:

• Team must use Option 1 (complete the control)

• OPTION 3: Escalate

• Engineering Director and Security Lead jointly decide.

• Decision is documented regardless of outcome.

• Used only for genuine conflicts between business urgency and security.

⚠ REAL-WORLD: In the 2024 Change Healthcare attack, a critical production system lacked MFA — likely because it was "too difficult" or "going to be added later." A formal exception process would have forced someone to sign their name to "I accept the risk of no MFA on this critical system" — and that exception would have appeared on executive dashboards quarterly. Social pressure and accountability often drive completion faster than any technical control.

Emergency Release Flow

For genuine emergencies (critical production bug, active exploit requiring immediate patch):

• Developer submits emergency change request in ServiceNow

• (Includes: what is the emergency, what is the blast radius, what control is incomplete)

• Expedited approval: Security Lead + Engineering Director

• (SLA: respond within 30 minutes for P1 emergencies)

• If approved, conditions are set:

• Time-bound exception (typically 7–14 days to remediate)

• Risk acceptance is documented with approver names

• Post-deploy action items are created with hard deadlines

• Monitoring is enhanced for the exception period

• Pipeline receives override token → deployment proceeds

• ServiceNow creates follow-up task

• If not resolved within the exception window → escalation path begins

• If the same exception is requested twice → requires VP-level approval

Emergency releases are possible — but they are formal, approved, documented, time-bound, and tracked. Nobody "just deploys" without accountability.

Controls Are Defined Before Development, Not After

This is critical and bears emphasis:

• WRONG approach (reactive):

• Build product → discover vulnerabilities in production → scramble to define controls → retroactively fix

• RIGHT approach (proactive):

• Define controls → build them into the pipeline from day one → monitor continuously → fix gaps before they reach production

The correct sequence:

• PHASE 1: DEFINE (before development begins)

• GRC team and security architects define policies and control requirements.

• Document them in ServiceNow. Map to frameworks. Assign owners.

• This happens during planning, not after launch.

• PHASE 2: IMPLEMENT (during development)

• Product and engineering teams receive control requirements.

• They implement technically: configure Semgrep in CI, set branch protection, enable encryption, configure WAF.

• This is part of sprint work, not separate "security work."

• PHASE 3: VERIFY (continuous after implementation)

• Evidence flows back automatically to ServiceNow.

• Control tests confirm implementation is active and effective.

• If a control degrades → issue auto-created → assigned back to team.

How requirements reach product teams:

• ServiceNow (control defined) → Security team translates to actionable requirement → Appears in team's backlog (Jira ticket) → Engineer implements during sprint → Evidence flows back to ServiceNow confirming completion

End-To-End Lifecycle Example

Tracing one control through the complete GRC lifecycle:

• Control: BL-WEB-01 — SAST scanning must block merge on critical findings

• GOVERNANCE — Secure Coding Policy states: "All code must pass SAST scanning before merge to main branch."

• CONTROL DEFINED — Semgrep configured in GitHub Actions, runs on every PR, configured to fail the check on high or critical severity findings.

• RISK MITIGATED — Addresses R-001 (supply chain vulnerability) and R-004 (data exposure via insecure code patterns).

• COMPLIANCE MAPPED — Satisfies SOC 2 CC7.1, ISO 27001 A.14.2.1, NIST CSF DE.CM-4, PCI-DSS 6.5.x simultaneously.

• EVIDENCE COLLECTED — Every PR generates a Semgrep scan result artifact. ServiceNow collects these via GitHub API integration.

• CONTROL TESTED — Monthly automated test: ServiceNow queries GitHub API to confirm that branch protection rules still require the Semgrep status check to pass.

• DASHBOARD — CISO dashboard shows "BL-WEB-01: Passing" with green indicator. If someone disables the check or bypasses branch protection, status immediately flips to "Failing" and triggers an alert.

• AUDIT — External SOC 2 auditor opens ServiceNow, sees 12 months of continuous scan evidence, confirms the control is effective. Marks it as tested with no exceptions.

The Mapping Mental Model

• POLICY → defines what must happen

• CONTROL → makes it happen (the technical or procedural mechanism)

• RISK → explains why it matters (what bad outcome is prevented)

• FRAMEWORK → proves it satisfies external requirements (SOC 2, ISO, etc.)

• EVIDENCE → proves it is actually working (not just documented)

• GATE → prevents release without that proof

Key Takeaways

• Custom controls extend baselines for assets with unique risk profiles. Triggered by threat models, new regulations, incidents, or architectural uniqueness.

• Release gates are fully automated. The pipeline queries ServiceNow and gets approve or deny in real-time. No manual gatekeeping meetings for standard changes.

• Gate strictness scales with criticality. Critical assets require multiple approvals. Low-risk assets auto-approve when conditions are met.

• Emergency exceptions are formal and time-bound. They exist for real emergencies — but with full documentation, approval, and tracked follow-up.

• Controls are defined before development begins. ServiceNow is the system of record. Product teams implement. The pipeline enforces. Evidence proves it.

• Nobody ships without accountability. The pipeline physically cannot deploy without compliance verification. Skipping requires a documented, approved, traceable decision.

What Comes Next

In Part 6, we tackle the newest governance challenge: managing AI tools (Copilot, agents, LLMs) that product teams use daily — including AI-specific security baselines, the unique risks AI introduces, and how to govern AI usage within your existing GRC framework.

Previous: Part 4 — Security Baselines & Asset Mapping

Next: Part 6 — AI Governance — Managing AI Tools in Product Development