Every feature explained.
GRC Crest has seven operational tabs, each solving a distinct GRC challenge. This page documents every tab in full — what it does, how to use it, and what it replaces.
Architecture Overview
What it is: A visual, interactive map of the five GRC automation layers with live KPI metrics, tool stacks, and animated pipeline walkthroughs.
How to use it: Click on any of the five layer cards to expand a detail panel showing live KPI metrics, the tool stack, and an animated step-by-step pipeline. Each pipeline step lights up in sequence showing how events flow from trigger to resolution.
Who should use it: GRC architects, security engineers, directors reviewing the compliance posture, auditors wanting to understand the automation architecture.
This is the "control room" view of your entire GRC operation. At a glance you can see which layers are ACTIVE, STREAMING, or STANDBY — and drill into real-time metrics for each layer's toolchain.
Pipeline Detail
What it is: A full, linear view of every step in the end-to-end automation flow — from a developer's git commit all the way to an audit-ready evidence artefact. Of 14 pipeline steps, only 2 ever require human action.
Key insight: 12 of 14 steps are fully automated. Humans only intercept the two steps that require genuine judgment — and those only fire for the three highest-stakes scenarios.
Code Reference
What it is: Production-ready code samples for each of the five GRC layers — OPA Rego rules, GitHub Actions steps, TypeScript remediation scripts, AI agent logic, and escalation trigger guards. Each card has a COPY button. These are not pseudocode — they are the actual rule patterns used in production.
AI Vendor Risk Assessment
What it replaces: A GRC analyst typically spends 4–8 hours reviewing a vendor's SOC 2 report, cross-referencing requirements, scoring gaps, and drafting a response. This tab does the same work in under 60 seconds.
| Output | Description |
|---|---|
| Risk Score (0–100) | Numerical residual risk. 0 = meets all requirements. 100 = critical failures across the board. |
| Risk Level | LOW / MEDIUM / HIGH / CRITICAL — categorical label for quick triage. |
| Control Gaps | Every gap found, with severity and a specific remediation recommendation. |
| Strengths | Security controls the vendor has correctly implemented. |
| Draft Email | Professional email to the vendor citing gaps and requesting remediation timelines. Ready to send after your review. |
| Audit Trail Note | One-line entry auto-formatted for the compliance evidence log. |
| Control | What Is Checked |
|---|---|
| MFA on privileged accounts | Is multi-factor authentication enforced for all admin access? |
| Encryption at rest | Is data encrypted using AES-256 minimum? |
| Incident response SLA | Can the vendor respond to a P1 incident within 4 hours? |
| Certification | Does the vendor hold SOC 2 Type II or ISO 27001? |
| Penetration testing | Has a pentest been conducted within the last 12 months? |
| Sub-processor disclosure | Have all third parties who process your data been disclosed? |
| GDPR data residency | Is data storage compliant with GDPR Article 46 transfer rules? |
OPA Rule Generator
What it replaces: Writing OPA Rego requires specialist knowledge most GRC professionals don't have. A GRC team historically writes a policy in Word, then waits days for a platform engineer to implement it — with the risk of misinterpretation. This tab closes that gap instantly.
| Artefact | What It Is | Where It Goes |
|---|---|---|
| OPA Rego Rule | Complete deny block with package declaration | Your OPA instance |
| Semgrep YAML Rule | Code-level static analysis rule | Your Semgrep ruleset |
| GitHub Actions Step | YAML CI step running conftest | .github/workflows/compliance.yml |
| Terraform / Checkov | Infrastructure-as-code guardrail | Pre-commit hooks and CI pipelines |
| Test Cases | DENY/ALLOW assertions | policy_test.rego |
- Install its Vercel AI SDK package:
npm install @ai-sdk/your-provider - Add a
casein thegetModel()switch insrc/app/api/ai/route.ts - Add the required env vars to
.env.example - Update the
AIProvidertype insrc/types/grc.ts
Evidence Tracker
What it replaces: Before annual audits, GRC teams spend 2–4 weeks manually collecting evidence. This tab eliminates that entirely — evidence is collected on a continuous schedule by AI agents so when the auditor arrives, a live timestamped dashboard is already waiting.
- Use framework filter tabs (ALL / SOC 2 / ISO 27001 / NIST 800-53) to focus on a specific standard
- Click any row to see: evidence on file, last checked timestamp, next due date, collection owner (AUTO or HUMAN)
- For AUTO-owned FAIL or WARN controls, click COLLECT to trigger an immediate AI collection run
A US auditing framework for technology companies. Controls cover security, availability, processing integrity, confidentiality, and privacy. Required by most enterprise customers before signing a SaaS contract.
The international standard for information security management systems (ISMS). Required in many regulated industries and government contracts.
US National Institute of Standards and Technology security control catalogue. Required for US federal IT systems; widely adopted as best practice.
Incident Response Playbook
What it is: A structured incident command centre with pre-loaded real-world incident scenarios, automated response timelines, and AI-powered root cause analysis. When a security incident fires, the AI agent analyses the attack vector, blast radius, and timeline before a human opens the alert.
- Select an incident from the left panel
- Read the automated response timeline — each step labelled AUTO or HUMAN
- Read the AI Incident Narrative — plain-English summary of what happened
- Read the GRC Architect Recommendation — specific remediation steps
- Click GENERATE AI ROOT CAUSE ANALYSIS
- Root cause determination
- Attack vector explanation
- Ordered immediate action list
- Policy gaps surfaced by this incident
- OPA Rego rule to prevent recurrence
- Whether executive escalation is recommended
| Level | Meaning | Response |
|---|---|---|
| P1 | Critical — active breach or data at risk | Auto-contained in seconds; human review within 30 minutes |
| P2 | High — significant misconfiguration or near-miss | Auto-blocked; human review within 2 hours |
| P3 | Medium — policy violation without immediate risk | Auto-logged; human review within 24 hours |
How every request is secured
1. Any request arrives → middleware reads JWT cookie
2. Checks: session exists AND mfaVerified === true
✗ → redirect to /login (302)
✓ → request proceeds
3. /login: user submits email + password
→ bcrypt.compare() against AUTHORISED_USERS
✓ → partial session (mfaVerified: false)
4. MFA step: user submits 6-digit code
→ verifyTOTP() or verifyEmailOTP()
✓ → updateSession({ mfaVerified: true })
→ redirect to dashboard
5. AI feature triggered → POST /api/ai
→ auth() check: mfaVerified: true required
→ getModel() reads AI_PROVIDER env var
→ generateText() via Vercel AI SDK
→ API keys: process.env only, never browser
| Property | Implementation |
|---|---|
| API keys never in browser | All LLM calls go through /api/ai server route. Keys only in process.env. |
| Auth enforced at middleware | Every request passes through src/middleware.ts before rendering. |
| MFA required for AI features | /api/ai checks mfaVerified: true independently of middleware. |
| Password storage | bcrypt with cost factor 12 — not reversible. |
| Session token | httpOnly cookie — inaccessible to JavaScript. No XSS token theft. |
| Brute-force prevention | MFA verify: 5 attempts / 15 min. Email OTP send: 3 sends / 15 min. |
| User enumeration prevention | Step 1 always returns "Invalid credentials" — never "User not found". |
| TOTP window | ±1 step (30s tolerance) — accommodates clock skew. |
| Email OTP single-use | Deleted from store immediately after successful verification. |
| Session expiry | 8 hours — forces daily re-authentication. |
Definitions of every term
Every technical term used in GRC Crest, defined in plain English so non-technical colleagues and executives can read the platform without a security or engineering background.
A way for software systems to communicate. When GRC Crest calls the Claude or OpenAI API, it sends a structured request to their servers and receives a structured response.
A separate password generated specifically for an application to use with your email account — without giving the application access to your main account password. Required for Gmail SMTP access.
A chronological, tamper-resistant record of events. In compliance, an audit trail proves to auditors that security controls operated correctly during a specific period.
A password hashing algorithm. Instead of storing a user's password, the system stores an irreversible mathematical transformation of it. Even if the database is stolen, the original passwords cannot be recovered.
The scope of damage if a security incident is not contained — which systems are affected, what data is at risk, and how many users are impacted.
A standardised security questionnaire from the Cloud Security Alliance used to assess cloud vendor security practices.
The practice of monitoring security controls in real time rather than checking them once per year at audit time. GRC Crest implements CCM via live event streaming from CloudTrail and Prometheus.
An open-source static analysis tool for infrastructure-as-code (Terraform, CloudFormation). Checks configuration files for security and compliance violations before infrastructure is deployed.
The automated process that takes code written by a developer, runs checks and tests on it, and deploys it to production. GRC Crest embeds compliance checks (gates) directly into this pipeline.
An AWS service that records every API call made in an account — who did what, when, from where. The equivalent of a CCTV system for cloud infrastructure.
A piece of data stored in the browser. An httpOnly cookie cannot be read by JavaScript — only sent automatically by the browser to the server. This prevents session tokens from being stolen by malicious scripts (XSS attacks).
A 0.0–10.0 score measuring the severity of a software security vulnerability. Scores of 7.0–8.9 are "High"; 9.0–10.0 are "Critical". GRC Crest blocks builds automatically when a CVSS score is 8.0 or above.
A publicly listed software vulnerability with a unique identifier (e.g. CVE-2024-3811). CVEs are published when security flaws are discovered in software libraries.
A tool built into GitHub that automatically detects and creates pull requests to update software dependencies when vulnerabilities are found.
The practice of integrating security into the DevOps software development and operations workflow — making security a continuous, automated part of development rather than a final checkpoint.
When the actual configuration of a live system diverges from its approved baseline. For example, if an IAM role has extra permissions that were not approved.
The European Union's data protection regulation. Governs how personal data of EU residents must be collected, stored, processed, and transferred. Non-compliance carries fines of up to 4% of global annual turnover.
Governance: The policies, procedures, and frameworks that guide decision-making. Risk: The identification, assessment, and management of threats. Compliance: Ensuring the organisation meets all applicable laws, regulations, and standards.
The practice of expressing GRC policies, controls, and procedures as machine-readable code stored in version control — rather than as Word documents, PDFs, or spreadsheets.
The system that controls who can access what in AWS. IAM policies define permissions; IAM roles are assigned to services and users.
The international standard for Information Security Management Systems (ISMS). Companies achieve ISO 27001 certification by implementing a systematic set of security controls and undergoing independent audit.
A compact, digitally signed token used to store session information. The signature ensures the token cannot be tampered with. GRC Crest stores the JWT in an httpOnly cookie.
An AI model trained on vast amounts of text data, capable of understanding and generating human-like text. Claude (Anthropic) and GPT-4o (OpenAI) are LLMs used by GRC Crest.
A security mechanism requiring users to verify their identity using two or more methods (e.g. password + phone code). GRC Crest implements MFA as: something you know (password) + something you have (authenticator app or email access).
An open-source workflow automation tool used to trigger remediation scripts automatically when compliance violations are detected.
A security control catalogue published by the US National Institute of Standards and Technology. Required for US federal government IT systems; widely adopted as best practice.
An open-source policy engine that allows you to define and enforce rules across infrastructure using a language called Rego. The core engine of GRC Crest's Policy-as-Code layer.
The Node.js library used to generate and verify TOTP codes (RFC 6238). Compatible with Google Authenticator, Authy, and all standard TOTP apps.
The practice of writing compliance and security policies as machine-readable code so they can be version-controlled, tested, and automatically enforced by computers.
A simulated cyberattack performed by security professionals to identify vulnerabilities before real attackers can exploit them. Most compliance frameworks require an annual pentest.
An open-source monitoring and alerting system used to collect and stream real-time metrics from infrastructure — feeding the Continuous Controls Monitoring layer.
An AI technique where a language model is given access to a specific database of documents so it can retrieve relevant information before generating a response. Used in the vendor risk agent to match reports against the corporate rubric.
Restricting how many times an action can be performed in a given time window. GRC Crest rate-limits MFA verification (5 attempts / 15 minutes) and email OTP sends (3 sends / 15 minutes) to prevent brute-force attacks.
The policy language used by Open Policy Agent. Written in a logic-based syntax, Rego rules evaluate input data and return decisions (allow/deny). Example: a Rego rule that denies any S3 bucket with a public ACL.
A formal decision by an organisation to accept a known security risk rather than fix it — typically because the fix would cause more harm than the risk itself. Requires documented sign-off and is one of the three categories that always escalates to a human in GRC Crest.
An open-source static analysis tool that scans source code for security vulnerabilities and policy violations. Semgrep rules can be customised to enforce organisation-specific patterns.
The standard protocol for sending email. GRC Crest uses SMTP (via Nodemailer) to deliver email OTP codes.
A US auditing framework for technology companies. SOC 2 Type I is a point-in-time assessment; SOC 2 Type II covers a period (typically 6–12 months). Almost all enterprise SaaS customers require a SOC 2 Type II report before signing contracts.
An infrastructure-as-code tool that allows engineers to define cloud infrastructure in configuration files. OPA rules can evaluate Terraform plans before resources are deployed.
A standard (RFC 6238) for generating short-lived codes using a shared secret. Google Authenticator implements TOTP. Codes change every 30 seconds and cannot be reused.
An open-source tool that scans git repositories and commits for accidentally exposed secrets (API keys, passwords, tokens).
A typed superset of JavaScript. TypeScript adds static types that are checked at compile time — catching contract errors before runtime. GRC Crest uses strict TypeScript 5.8.
The official AI library from Vercel. Provides a unified generateText() function that works with Anthropic Claude, OpenAI GPT, and any OpenAI-compatible endpoint — eliminating provider-specific request/response code.
A detailed security questionnaire sent to vendors to assess their security posture before onboarding.