BUILDING A BULLETPROOF GRC PROGRAM — Part 4 of 8: Security Baselines, Asset Mapping & Ownership…

What Is A Security Baseline?

A security baseline is the minimum set of mandatory controls that every asset must implement before going to production. It is the non-negotiable foundation — not optional, not aspirational, not "we'll get to it later." Required.

Think of it like building codes for construction. You cannot skip fire exits because you are in a rush to open the building. Similarly, you cannot skip SAST scanning because you are racing to a release deadline.

⚠ REAL-WORLD: The 2024 Snowflake-related breaches (AT&T, Ticketmaster, Santander — 165+ organizations, billions of records) happened because there was no enforced baseline requiring MFA on all accounts. The security feature existed but was optional. A baseline would have made it mandatory. Instead, stolen credentials from infostealer malware provided direct access.

Baselines By Asset Type

Different asset types face different threats. The baseline is tailored accordingly.

WEB APPLICATION BASELINE (10 controls):

• BL-WEB-01 SAST scanning in CI pipeline Priority: P1

• BL-WEB-02 SCA dependency scanning Priority: P1

• BL-WEB-03 DAST scanning in staging Priority: P2

• BL-WEB-04 Peer code review enforced (min 1 approver) Priority: P1

• BL-WEB-05 Input validation on all user-facing endpoints Priority: P1

• BL-WEB-06 Authentication with MFA for admin access Priority: P1

• BL-WEB-07 TLS 1.2+ enforced for all connections Priority: P1

• BL-WEB-08 Security logging enabled and forwarded to SIEM Priority: P1

• BL-WEB-09 WAF deployed in front of application Priority: P2

• BL-WEB-10 Secrets scanning — no hardcoded credentials Priority: P1

API SERVICE BASELINE (7 controls):

• BL-API-01 SAST scanning in CI Priority: P1

• BL-API-02 SCA dependency scanning Priority: P1

• BL-API-03 Rate limiting configured on all endpoints Priority: P1

• BL-API-04 OAuth2/JWT auth with token rotation Priority: P1

• BL-API-05 Input schema validation (reject malformed requests) Priority: P1

• BL-API-06 Sensitive data never logged (mask PII, tokens) Priority: P1

• BL-API-07 Mutual TLS for internal service-to-service calls Priority: P2

DATABASE BASELINE (6 controls):

• BL-DB-01 Encryption at rest using AES-256 or equivalent Priority: P1

• BL-DB-02 Individual access control — no shared accounts Priority: P1

• BL-DB-03 Automated backups with tested restore procedure Priority: P1

• BL-DB-04 Audit logging enabled for all access Priority: P1

• BL-DB-05 No public network exposure Priority: P1

• BL-DB-06 Connection encryption via TLS Priority: P1

CLOUD INFRASTRUCTURE BASELINE (6 controls):

• BL-INF-01 IaC scanning (Checkov, tfsec) before apply Priority: P1

• BL-INF-02 Least-privilege IAM — no wildcard permissions Priority: P1

• BL-INF-03 Encryption enabled for storage and transit Priority: P1

• BL-INF-04 Network segmentation — workloads isolated Priority: P1

• BL-INF-05 Monitoring and alerting configured Priority: P1

• BL-INF-06 No default or vendor-provided credentials in use Priority: P1

CONTAINER AND MICROSERVICE BASELINE (6 controls):

• BL-CON-01 Image scanning (Trivy, Snyk) on build Priority: P1

• BL-CON-02 No root user execution in container Priority: P1

• BL-CON-03 Secrets via vault or secrets manager, not env vars Priority: P1

• BL-CON-04 Network policies defined and enforced Priority: P1

• BL-CON-05 Health checks implemented (readiness + liveness) Priority: P1

• BL-CON-06 Resource limits set (CPU and memory) Priority: P2

Asset Inventory (Cmdb)

Every asset in the organization is registered with key metadata:

• APP-001 — Customer Portal

• Type: Web Application

• Criticality: Critical

• Business Unit: Retail

• Environment: Production

• Data Classification: Confidential (contains PII)

• Asset Owner: Product Director, Retail

• Tech Lead: Senior Engineer, Portal Team

• APP-002 — Payment Service

• Type: API Service

• Criticality: Critical

• Business Unit: Payments

• Environment: Production

• Data Classification: Restricted (contains payment card data)

• Asset Owner: VP Payments

• Tech Lead: Lead Engineer, Payments API

• DB-001 — Customer Database

• Type: Database

• Criticality: Critical

• Business Unit: Retail

• Environment: Production

• Data Classification: Confidential (PII)

• Asset Owner: Data Director

• Tech Lead: Platform Lead

• INF-001 — AWS Production VPC

• Type: Cloud Infrastructure

• Criticality: Critical

• Business Unit: Platform

• Environment: Production

• Asset Owner: VP Engineering

• Tech Lead: Infrastructure Lead

Essential CMDB fields for every asset:

• Unique asset identifier

• Human-readable name

• Asset type (determines baseline template)

• Criticality rating (determines gate strictness and SLA priority)

• Business unit

• Environment (dev, staging, production)

• Data classification (public, internal, confidential, restricted)

• Asset owner (business accountability)

• Technical lead (implementation accountability)

Automatic Baseline Assignment

When an asset is registered, its type determines which baseline applies automatically:

• Asset type = "Web Application" → auto-apply BL-WEB-01 through BL-WEB-10

• Asset type = "API Service" → auto-apply BL-API-01 through BL-API-07

• Asset type = "Database" → auto-apply BL-DB-01 through BL-DB-06

• Asset type = "Cloud Infrastructure" → auto-apply BL-INF-01 through BL-INF-06

• Asset type = "Container" → auto-apply BL-CON-01 through BL-CON-06

No human decision needed. No meetings to determine "which controls apply." Register the asset, baseline applies, implementation tasks are created with owners and due dates.

Example: How Controls Map For A Specific Asset

Asset: APP-001 (Customer Portal) — Web Application, Critical

• BL-WEB-01 — SAST scanning in CI

• Frameworks satisfied: SOC2-CC7.1, NIST-DE.CM-4

• Priority: P1

• Status: Complete

• Owner: Dev Lead

• Evidence: GitHub Actions scan artifacts (continuous)

• BL-WEB-02 — SCA dependency scanning

• Frameworks satisfied: SOC2-CC7.1, PCI-6.2

• Priority: P1

• Status: Complete

• Owner: Dev Lead

• Evidence: Snyk reports (continuous)

• BL-WEB-03 — DAST scanning in staging

• Frameworks satisfied: SOC2-CC7.1

• Priority: P2

• Status: In Progress (implementation ongoing)

• Owner: Security Engineer

• Due: August 2026

• BL-WEB-09 — WAF deployed

• Frameworks satisfied: NIST-PR.PT-4

• Priority: P2

• Status: Not Started

• Owner: Platform Team

• Due: September 2026

• Overall baseline completion: 8 out of 10 controls (80%)

Ownership Model

Accountability is layered. Everyone knows their specific responsibility:

• LEVEL 1 — CISO / Security Leadership

• Owns: The overall baseline definition (what controls must exist)

• Accountable for: Organization-wide compliance posture

• Decides: Which controls are P1 versus P2, when baselines are updated

• LEVEL 2 — GRC Team

• Owns: Framework mapping, control definitions, evidence requirements

• Accountable for: Tracking progress, reporting status, audit readiness

• Does: Configures ServiceNow, validates evidence, prepares reports

• LEVEL 3 — Product / Engineering Director

• Owns: All assets within their business unit

• Accountable for: Ensuring their teams implement the baseline on time

• Escalated to: When teams fall behind on implementation

• LEVEL 4 — Tech Lead (per asset)

• Owns: Specific asset's compliance with baseline

• Accountable for: Implementing controls and maintaining them over time

• Reports: Status updates, flags blockers, provides evidence

• LEVEL 5 — Individual Engineer (per task)

• Assigned: Specific control implementation tasks

• Accountable for: Completing by due date, providing implementation evidence

• Example: "Configure Semgrep in CI for repo X by January 15"

ServiceNow fields that capture this:

• Asset Owner — who answers for this asset to leadership

• Control Owner — who ensures the control is working technically

• Task Assignee — who is doing the implementation work right now

• Risk Owner — who accepts residual risk if a control cannot be implemented

• Approver — who signs off on exceptions or risk acceptance

Tracking Completion

Per-Asset Compliance View:

• Asset: APP-001 (Customer Portal) — Critical

• Baseline: 80% complete (8 of 10 controls)

• Complete: SAST, SCA, code review, input validation, auth/MFA, TLS, logging, secrets scan

• In Progress: DAST (due August 2026)

• Not Started: WAF (due September 2026)

• Overdue items: 0

• Deployment gate status: PASSING (all P1 controls are complete)

Organization-Wide View:

• Total assets tracked: 47

• Fully compliant (100% baseline): 12 assets (26%)

• On track (no overdue items): 28 assets (59%)

• At risk (has overdue items): 5 assets (11%)

• Not started: 2 assets (4%)

• Overall baseline coverage: 78%

• Target: 95% by end of Q4 2026

• Trajectory: On track (was 62% at start of Q1)

Lifecycle And Automation

How a control moves through its lifecycle:

• Step 1: New asset onboarded in CMDB

• Step 2: Baseline auto-applied based on asset type and criticality

• Step 3: Tasks created for control owner with specific due dates

• Step 4: Automated reminders sent at 30 days, 14 days, and 7 days before due

• Step 5: Owner marks control as implemented and provides evidence

• Step 6: GRC team validates evidence (or automated test confirms)

• Step 7: Control status moves to "Effective"

• Step 8: Continuous monitoring begins — periodic automated re-testing

• Step 9: If control degrades (test fails), status moves to "Failing"

• Step 10: Auto-reopened as a task, assigned back to control owner

Escalation when items are overdue:

• Due date passes → Day 1: Auto-reminder sent to assignee

• Day 7: Escalation notification sent to tech lead

• Day 14: Escalation to engineering director

• Day 30: Escalation to CISO, item flagged in board report

• Day 45: Forced decision required — complete the control or formally accept the risk

• Each escalation is logged, all parties notified, risk score adjusted upward, and the item becomes visible in executive dashboards.

New Asset Onboarding

When a product team creates a new service or application:

• Asset is registered in CMDB

• (Either manually by the team, or auto-discovered from cloud provider API)

• ServiceNow identifies asset type and criticality

• (Based on metadata: what type of service, what data does it handle)

• Baseline template is auto-applied

• (Generates all required control tasks without human intervention)

• Tasks are assigned to asset owner with implementation timeline

• (Timeline based on criticality — critical assets get shorter deadlines)

• Production deployment gate is enforced

• (The CI/CD pipeline will not deploy to production until P1 controls are verified)

• Example: Team registers "Notification Service" as an API Service, Medium criticality.

• → Auto-assigned: BL-API-01 through BL-API-07 (7 controls)

• → Owner assigned: Team Lead

• → Due date: Launch date minus 2 weeks

• → Gate: Cannot request production change ticket until 100% P1 controls are complete

⚠ REAL-WORLD: In the 2023 Microsoft Storm-0558 breach, attackers accessed email accounts of US government officials via Azure Active Directory token forgery. A key contributing factor was a consumer signing key that should never have been accessible from the enterprise environment — an asset boundary control that was missing. Proper asset classification and baseline enforcement (separating consumer and enterprise key management) would have prevented the access path.

Key Takeaways

• Baselines are non-negotiable minimums. They are tailored by asset type, not one-size-fits-all. A database has different needs than a web application.

• Auto-assignment removes friction. Register an asset, baseline applies automatically, tasks are created. No meetings, no manual decisions about "which controls apply."

• Ownership is hierarchical and explicit. From CISO (defines what's required) to individual engineer (implements the specific task), everyone knows exactly what they are responsible for.

• Tracking is continuous with automated escalation. This is not a one-time checkbox. Controls are monitored permanently, and degradation triggers immediate re-assignment.

• New assets are gated. No production deployment without proven baseline compliance. This prevents the "we'll add security later" pattern that leads to breaches.

What Comes Next

In Part 5, we cover how custom controls extend baselines for assets with unique risk profiles, and how the build/release process is gated by ServiceNow sign-off — ensuring nothing ships to production without proven, verified compliance.

Previous: Part 3 — ServiceNow GRC

Next: Part 5 — Custom Controls, Release Gates & ServiceNow Sign-Off