A Unified Security Operations & GRC Platform — Built to mirror enterprise ServiceNow SecOps + GRC workflows from the ground up

I built CyberGRC Hub because I wanted Toyota's team to see exactly how I think about their problem — before I ever walked into the interview room.

Let me tell you the story.

Enterprise GRC tools like ServiceNow cost $500,000+ annually in licensing. That's not a typo. Security teams spend more time fighting the tool than managing actual risk. Most GRC platforms are black boxes — engineers click buttons, approve workflows, and never understand why a risk score changes from "Medium" to "High" overnight.

Here's what I observed: teams become tool administrators rather than risk professionals. They learn the click paths but lose sight of the domain logic.

If you truly understand GRC domain logic — risk scoring algorithms, control mapping relationships, incident state machines, compliance framework hierarchies — you can rebuild the core workflows from scratch. More importantly, you learn more in 3 months of building than most ServiceNow admins learn in 3 years of clicking.

I didn't want to be the "guy who took a ServiceNow certification course." I wanted to be the engineer who could look at a risk register, understand the math behind the scoring, and explain to a CISO why their residual risk calculation might be wrong.

I built every module Toyota's Cyber Fusion Center uses daily:

• Policy & Compliance Management — mapping controls to NIST CSF, ISO 27001, SOX, and TISAX
• Risk Register with Automated Scoring — 5×5 likelihood × impact matrix with full audit trail
• Security Incident Response — structured state machine with SLA enforcement per severity
• Vulnerability Response — automated CVE ingestion, deduplication, and remediation task creation
• Integration Hub — Splunk, Qualys, Tanium, and ServiceNow connectivity

This project isn't just a portfolio piece. It's proof of domain ownership.

When I sit across from Toyota's GRC team, I won't be asking "what does this button do." I'll be asking "how do you handle risk exceptions when the control owner is unavailable for 30 days?" That's the difference between a candidate and a contributor.

┌─────────────────────────────────────────────────────────────────────────────┐
│                           EXTERNAL INTEGRATIONS                               │
├──────────────────┐  ┌──────────────────┐  ┌──────────────────────────────────┐
│   Splunk SIEM    │  │  Qualys Scanner │  │         Tanium Agent            │
│  ──────────────  │  │  ──────────────  │  │        ─────────────            │
│  REST Webhook   │  │  REST Poll       │  │        REST Pull                 │
│  Alert → JSON   │  │  Scheduled → JSON│  │        On-demand → JSON          │
└────────┬─────────┘  └────────┬─────────┘  └───────────────┬────────────────┘
         │                      │                             │
         └──────────────────────┼─────────────────────────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │   Integration Hub     │
                    │        (Go)           │
                    │  ─────────────────    │
                    │  Retry Logic          │
                    │  Dead-Letter Queue   │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │   Redis Event Queue   │
                    │  ─────────────────    │
                    │  SLA Timers           │
                    │  WebSocket Pub/Sub   │
                    └───────────┬───────────┘
                                │
         ┌──────────────────────┼──────────────────────┐
         │                      │                      │
         ▼                      ▼                      ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│  GRC Engine    │  │  SecOps Engine  │  │      CMDB      │
│  Policy/Comp   │  │  Incidents/Vuln │  │   CI Registry  │
│  Risk Register │  │  Response      │  │   Topology     │
└────────┬────────┘  └────────┬────────┘  └────────┬────────┘
         │                    │                    │
         └────────────────────┼────────────────────┘
                              │
                              ▼
                   ┌─────────────────────┐
                   │   PostgreSQL       │
                   │  ──────────────   │
                   │  Risk/Incident    │
                   │  Compliance Data  │
                   └─────────┬─────────┘
                             │
                             ▼
                   ┌─────────────────────┐
                   │  React Dashboard   │
                   │  ───────────────    │
                   │  Recharts + D3.js  │
                   │  WebSocket Live     │
                   └─────────────────────┘
                             │
                             ▼
              ┌──────────────────────────────┐
              │     AWS ECS + RDS            │
              │  (Production Deployment)     │
              └──────────────────────────────┘

What this does: CyberGRC Hub's Policy & Compliance module lets security teams create policies, map them to regulatory controls (NIST CSF, ISO 27001, SOX, TISAX), collect evidence of compliance, and track review cycles — all in one system instead of scattered spreadsheets.

How it works technically: Policies are stored in PostgreSQL with a one-to-many relationship to controls. Each control has an evidence_url field pointing to stored documents, a last_reviewed timestamp, and a reviewer_id reference. The compliance posture is calculated via a SQL aggregation that sums compliant controls divided by total controls per framework. When a policy is created, a Kafka event triggers the control mapping workflow.

flowchart TD
    A[Policy Created] --> B{Controls Mapped?}
    B -->|No| C[Assign Control Owner]
    C --> D[Control Owner Maps Controls]
    D --> B
    B -->|Yes| E{Evidence Collected?}
    E -->|No| F[Request Evidence Upload]
    F --> E
    E -->|Yes| G[Reviewer Approves Evidence]
    G --> H{Compliant?}
    H -->|Yes| I[Mark Compliant]
    H -->|No| J[Create Exception]
    J --> K[Risk Accepted/Remediated]
    I --> L[Update Compliance Posture]
    K --> L

What this does: The Risk Register captures every risk in the organization, calculates its inherent and residual scores using a standardized 5×5 likelihood × impact matrix, and tracks it through its complete lifecycle — from initial identification through mitigation, acceptance, or transfer.

How it works technically: Risks are Go structs stored in PostgreSQL with fields for inherent_score, residual_score, likelihood (1-5), impact (1-5), threat_actor, vulnerability, and control_effectiveness. The scoring engine automatically calculates residual_score = inherent_score × (1 - control_effectiveness). Risk appetite thresholds trigger alerts when residual risk exceeds configured limits. All state transitions are logged with timestamps and actor IDs for audit compliance.

stateDiagram-v2
    [*] --> Identified
    Identified --> Assessed : Risk Assessment Complete
    Assessed --> Mitigated : Controls Implemented
    Mitigated --> Accepted : Risk Owner Accepts Residual
    Mitigated --> Transferred : Insurance/Outsourcing
    Mitigated --> Closed : Review Complete
    Accepted --> Closed
    Transferred --> Closed
    Accepted --> [*]
    Transferred --> [*]
    Closed --> [*]

What this does: When a security incident occurs (malware detection, phishing, unauthorized access), CyberGRC Hub orchestrates the entire response — from initial detection through containment, eradication, recovery, and post-incident review — with SLA timers that escalate automatically if deadlines are missed.

How it works technically: Incidents follow a state machine implemented in Go with a PostgreSQL state table. SLA timers are enforced via Redis: when an incident transitions to a state, a TTL-based key is set (P1: 4hr, P2: 24hr, P3: 72hr). A background goroutine monitors for expired keys and escalates to the incident owner's manager via webhook. All notes, evidence, and timeline entries are append-only and cryptographically signed.

stateDiagram-v2
    [*] --> Detected
    Detected --> Triage : Analyst Assigns
    Triage --> Containment : Severity Confirmed
    Containment --> Eradication : Threat Isolated
    Eradication --> Recovery : Systems Restored
    Recovery --> PostIncidentReview : Recovery Complete
    PostIncidentReview --> Closed : Lessons Learned Logged
    Closed --> [*]
    
    Detected --> Escalated : SLA Breach (P1: 4hr)
    Triage --> Escalated : SLA Breach (P2: 24hr)
    Containment --> Escalated : SLA Breach (P3: 72hr)
    Escalated --> Triage : Manager Override
    Escalated --> Containment : Manager Override

What this does: CyberGRC Hub automatically ingests vulnerability scan results from Qualys or Nessus, deduplicates findings by CVE-ID and affected asset, maps each vulnerability to the corresponding CMDB Configuration Item, and creates remediation tasks with automatic SLA timers based on CVSS severity.

How it works technically: The /api/v1/scans/ingest endpoint accepts JSON scan reports. A Go worker parses the report, extracts CVEs, and uses a Bloom filter for deduplication against PostgreSQL's vulnerability_findings table. Each finding is matched to a CMDB CI via hostname/IP fingerprinting using a Levenshtein distance algorithm. Remediation tasks are created in the remediation_tasks table with SLA windows derived from CVSS scores (Critical: 24hr, High: 7d, Medium: 30d, Low: 90d).

flowchart TD
    A[Scan Ingested] --> B[Parse CVE List]
    B --> C{Duplicate CVE?}
    C -->|Yes| D[Update Existing Finding]
    C -->|No| E[Create New Finding]
    D --> F
    E --> F{Asset Matched?}
    F --> G[Match to CMDB CI]
    G --> H[Create Remediation Task]
    H --> I[Start SLA Timer]
    I --> J{Remediation Complete?}
    J -->|Yes| K[Close Task]
    J -->|No| L{SLA Breached?}
    L -->|Yes| M[Escalate to Manager]
    M --> J
    K --> N[Update Vulnerability Stats]

What this does: The Integration Hub connects CyberGRC Hub to the security tools already in your environment — Splunk for threat detection, Qualys and Tanium for vulnerability data — using industry-standard REST APIs with enterprise-grade retry logic and dead-letter queue handling.

How it works technically: Each integration is a Go goroutine with a configurable polling interval or webhook receiver. The base integration struct implements exponential backoff (initial: 1s, max: 60s, multiplier: 2) with a max of 3 retries before moving to the dead-letter queue in Redis. Authentication uses OAuth2 for Qualys/Tanium and API keys for Splunk. All inbound data is validated against JSON schemas before processing.

Retry Logic Details:

• Exponential backoff: 1s → 2s → 4s → 8s → 16s → 32s → 60s (max)
• Dead-letter queue: Failed messages stored in Redis with 7-day TTL
• Alert on 3 consecutive failures: Email + webhook to on-call engineer
• Manual replay: DLQ messages can be re-processed via admin API

The CyberGRC Hub executive dashboard provides real-time visibility into security posture and GRC metrics. All KPIs update via WebSocket push — no page refresh required.

Dashboard updates in real-time via WebSocket. All views can be exported to PDF for executive reporting with a single click.

This section signals senior engineering maturity — we think like security engineers, not just developers.

CyberGRC Hub implements defense-in-depth authentication with JWT tokens and role-based access control.

• JWT Tokens: 15-minute expiry with refresh token rotation. Refresh tokens are opaque UUIDs stored in PostgreSQL and invalidated upon use.
• RBAC: Four roles with granular permissions:

• Secrets Management: All secrets stored in AWS Secrets Manager (never committed to .env files)
• Encryption at Rest: PostgreSQL data encrypted via AWS RDS encryption (AES-256)
• Transport Security: TLS 1.3 enforced on all API endpoints (Go tls.Config with MinVersion: tls.VersionTLS13)
• Column-Level Encryption: Sensitive fields (CVE details, incident notes) encrypted via AES-256-GCM

• Rate Limiting: 100 requests/minute per API key (configurable per-role)
• Input Validation: All endpoints use Go struct tags with validate package (e.g., validate:"required,email")
• SQL Injection Prevention: Parameterized queries only — no raw string concatenation. All queries use pgx prepared statements.
• Audit Logging: Every write operation logs actor, timestamp, resource, before-state, and after-state to the audit_log table

In real GRC platforms, most users should NEVER have write access. This is a concept junior developers rarely think about.

Here's why: A junior analyst accidentally closing 50 incidents because they "looked resolved" could destroy the audit trail. A manager changing a risk score from "Critical" to "Low" without documented justification creates legal liability during SOX audits.

The Executive Viewer and Analyst roles in CyberGRC Hub are read-only by design. They can consume dashboards, view incidents, and export reports — but they cannot modify risk scores, close incidents, or approve controls. This mirrors exactly how Toyota's Cyber Fusion Center operates: analysts analyze, engineers execute, managers approve.

TISAX (Trusted Information Security Assessment Exchange) is the automotive industry's information security standard, required by Toyota, BMW, Volkswagen, and other OEMs from their suppliers and partners.

TISAX is a standardized assessment based on ISO 27001, but with automotive-specific controls for:

• Prototype protection (preventing leak of new vehicle designs)
• Data privacy (customer driving data, connected car telemetry)
• Secure development (software in automotive systems)
• Supplier security (third-party risk management)

Toyota requires TISAX compliance from all partners accessing their systems — making it a non-negotiable requirement for anyone working with their Cyber Fusion Center.

CyberGRC Hub includes a pre-loaded TISAX control library mapped to the same control families as NIST CSF and ISO 27001 — eliminating duplicate evidence collection.

TISAX defines three assessment levels (AL). CyberGRC Hub maps these to risk tiers:

This was built specifically because Toyota requires TISAX compliance from partners — knowing this framework before the interview is the difference between a candidate and a contributor.

CyberGRC Hub supports simultaneous multi-framework compliance, mapping controls across NIST CSF, ISO 27001, SOX, and TISAX to eliminate duplicate evidence collection.

Most GRC tools treat each framework in a silo — you upload evidence for ISO 27001, then upload the same evidence again for TISAX. CyberGRC Hub maps controls across all frameworks simultaneously:

• One piece of evidence satisfies multiple controls
• When a control is marked "compliant," all mapped frameworks update automatically
• Audit reports generate with framework-specific formatting from a single data source

This mirrors exactly how enterprise GRC teams handle overlapping compliance obligations — and eliminates the "compliance tax" of duplicate evidence collection.

Full OpenAPI/Swagger spec available at /api/docs when running locally

Get CyberGRC Hub running locally in 3 commands:

git clone https://github.com/cybergrchub/cybergrc-hub
cd cybergrc-hub
docker-compose up --build

Then open: http://localhost:3000

Default Login: admin@cybegrchub.local / changeme123

The ML risk scoring feature is particularly interesting because most GRC platforms use static scoring models. Anomaly detection on incident patterns could surface emerging risks before they're formally identified — that's the kind of proactive risk management Toyota's Cyber Risk Management team is trying to achieve.

I'm a full-stack engineer with 9+ years building high-throughput distributed systems, payment infrastructure, and real-time data pipelines. But this project isn't about my résumé — it's about how I think.

Payment systems taught me that risk is not abstract — a failed transaction costs real money, a missed compliance control costs real trust. I moved into GRC because I want to work on systems where the stakes are even higher.

This project demonstrates:

• Go backend development — Fiber framework, PostgreSQL, Redis, WebSocket servers
• Distributed systems thinking — Event-driven architecture, retry logic, dead-letter queues
• Database optimization — Complex joins for compliance reporting, indexing strategies
• AWS infrastructure — ECS, RDS, Secrets Manager, CloudWatch
• Security domain knowledge — NIST CSF, ISO 27001, SOX, TISAX frameworks
• Incident response — State machines, SLA enforcement, escalation paths
• Product thinking — ROI analysis, stakeholder communication, roadmap planning

I built CyberGRC Hub because I wanted Toyota's team to see exactly how I think about their problem — before I ever walked into the interview room.

• LinkedIn
• GitHub
• Live Demo
• Architecture Diagram

Built with ❤️ and a deep respect for the teams who keep enterprise systems secure

⭐ Star this repo if it helped you understand enterprise GRC workflows