Skip to content
SARC

What is SARC?

A plain-language introduction. Read this first if you’re new to SARC. Every concept gets a one-line definition the first time it appears.

In one sentence

Section titled “In one sentence”

SARC turns “are we compliant?” from a question your team answers with spreadsheets and screenshots into a question the system answers with live evidence — automatically, every time you ship.

In one paragraph

Section titled “In one paragraph”

Regulated organisations (banks, insurers, hospitals, governments) have to prove every software change met their compliance rules. Today that proof lives in pieces, scattered across many tools — code scanners, ticketing systems, deployment logs, audit dashboards. Someone has to collect those pieces by hand, every release and every audit. SARC removes the collecting. It plugs into the tools you already use (the Evidence Vault / Fides for evidence, ServiceNow for workflow, GitLab / GitHub / Azure DevOps for CI), gathers the evidence as it happens, and presents one auditor-ready story per change. The auditor logs in directly. The compliance director stops compiling spreadsheets. Engineers stop being the human glue.

Why does this matter?

Section titled “Why does this matter?”

Three pain points that show up in every regulated software team:

  1. The audit fire drill. When the regulator or auditor shows up, someone spends weeks reconstructing what happened in production over the past quarter. Most of the data exists somewhere — it’s just spread across 5–10 different tools, owned by different people, with no single timeline.
  2. The CAB bottleneck. Change Advisory Boards review every production change. A one-line config tweak gets the same 48-hour CAB queue as a database migration, because the system can’t tell the difference. Engineers wait. Customers wait. Risky changes slip through anyway because reviewers are tired by 30 changes in.
  3. The vendor-lock trap. Most compliance tooling is built around one cloud’s primitives. The day someone says “let’s move workloads to a second cloud,” the audit story breaks. Or the day someone says “let’s switch CI platforms,” the integrations break.

SARC removes all three.

How does it work — in plain terms

Section titled “How does it work — in plain terms”
flowchart TD
  A["Your developer pushes code"] --> B["Your CI builds, scans and tests it<br/>GitLab · GitHub · Azure DevOps"]
  B --> C["Each scan, build and test result is signed<br/>and saved as evidence — in Fides"]
  C --> D["A change request is created automatically,<br/>with the evidence attached — in ServiceNow"]
  D --> E["SARC scores the risk of this<br/>specific change — 5 dimensions"]
  E --> F{"How risky?"}
  F -->|"Low risk"| G["Auto-approved"]
  F -->|"Higher risk"| H["Goes to a human reviewer"]
  G --> I["Deploy"]
  H --> I
  I --> J["Every event is added to an audit log<br/>nobody can tamper with"]
  J --> K["Your auditor logs in directly<br/>and sees the evidence at source"]

  classDef ship fill:#0f2a1a,stroke:#2e7d52,color:#d7f5e3;
  classDef hold fill:#2a230f,stroke:#8a6d1f,color:#f5ead0;
  class G ship;
  class H hold;

The system is not a replacement for the Evidence Vault or ServiceNow or your CI — it’s the orchestration layer that wires them into one story. Each piece keeps doing its own job; SARC makes them work together.

Who uses it?

Section titled “Who uses it?”

SARC has surfaces for every role at the table — each person sees what’s relevant to them and nothing else:

Role What they care about
Compliance / GRC director Track framework coverage (SOC 2 / DORA / PSD2 / ISO / NIST / PCI / SOX), export evidence packs, answer auditor questions
Platform engineer Triage pipelines, vulnerabilities, policy violations; drive deployments through ArgoCD
Service owner / SRE Watch incidents on services they own; respond to problem records
Auditor (external, time-boxed) Read-only view of evidence + audit trail for one audit window
CFO / finance partner Cost roll-up, chargeback, cost-to-fix correlation on vulnerabilities
CEO / CTO The dashboard they show the board: “yes, we’re compliant, here’s the proof”
Admin / tenant operator User management, integrations, framework toggles

What it solves, in concrete terms

Section titled “What it solves, in concrete terms”
Before SARC After SARC
Audit prep = 1 person × 1 week × every quarter Audit prep = 1 click, generates a PDF
CAB reviews every change for 48 hours CAB reviews only risky changes; low-risk auto-approves
Evidence in 7 different tools Evidence in 1 portal, sourced from all 7
Compliance status known monthly Compliance status known per change, in real time
Cloud A vs Cloud B = different audit story Same audit story everywhere — pick the cloud
GitLab vs GitHub vs Azure DevOps = three different setups One pipeline shape; works on any of them
Auditor gets a PDF emailed to them Auditor logs into your portal, sees the source

What SARC is NOT

Section titled “What SARC is NOT”

To set expectations cleanly:

  • Not a SaaS — you install it in your own cloud and operate it.
  • Not a replacement for the Evidence Vault (evidence) or ServiceNow (workflow). They keep doing their own jobs.
  • Not a CI platform — bring your own (GitLab / GitHub / Azure DevOps).
  • Not a cloud — it deploys into yours (AWS / Azure / GCP / on-prem).
  • Not an authentication system — it uses your existing identity provider (Okta, Azure AD, etc.).
  • Not magic — it requires real integration with your real tools. Typical install: 4–8 weeks of engagement.

Three things to look at next

Section titled “Three things to look at next”

Pick the door that matches your role:

A few definitions, plain language

Section titled “A few definitions, plain language”

The rest of the docs assume you know what these mean. If you don’t — here they are:

  • Compliance framework — a checklist of rules an organisation must follow. Examples: SOC 2 (security baseline), DORA (EU operational resilience), PSD2 (EU payment services), PCI-DSS (handling card data), HIPAA (US health data).
  • CAB (Change Advisory Board) — a group of humans who approve production changes. Usually weekly. Often the bottleneck.
  • Evidence — proof that you actually did the things the framework requires. Used to be a paper trail; now usually JSON logs.
  • Attestation — a signed claim “X happened at time Y, here’s the proof.” Once signed it can’t be edited; tampering is detectable. SARC uses the Evidence Vault for these.
  • CR (Change Request) — a ticket that represents one production change. SARC creates these in ServiceNow automatically.
  • CI/CD pipeline — the automated steps that build, test, and deploy software when a developer pushes code.
  • GitOps — a deployment style where the state of production is described in git, and an in-cluster agent (ArgoCD) keeps the cluster matching git.
  • SBOM (Software Bill of Materials) — a list of every library and dependency in a built artifact. Used to answer “did we ship that vulnerable library?” instantly.
  • Risk clearance score — SARC’s per-change number that says how risky this change is, on 5 dimensions: change blast radius, vulnerability debt, evidence freshness, control coverage, and how this change compares to similar past changes.
  • Tenant — one isolated install of the portal for one organisation. Multi-tenant deploys can host several organisations on the same SARC instance.

When in doubt, check this list. The deeper docs link back here.