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

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

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 (Kosli 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?

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

Your developer pushes code
        ↓
Your CI builds, scans, tests it
        ↓
Each scan + build + test result is signed and saved as evidence (in Kosli)
        ↓
A change request is created automatically (in ServiceNow), with the evidence attached
        ↓
SARC computes a risk score for this specific change (5 dimensions)
        ↓
Low-risk changes auto-approve. Risky ones go to a human reviewer.
        ↓
After deploy, every event is added to an audit log nobody can tamper with
        ↓
Your auditor logs in directly. They see the evidence at source.

The system is not a replacement for Kosli 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?

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

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

To set expectations cleanly:

• Not a SaaS — you install it in your own cloud and operate it.
• Not a replacement for Kosli (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

Pick the door that matches your role:

• I’m evaluating SARC → read Why SARC for the executive case, then watch the demo videos.
• I’m going to install SARC → read the Architecture overview, then follow Getting started.
• I’m going to integrate with SARC → read the API overview + the MCP Gateway docs.

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 Kosli 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.