docs

Platform Architecture

AutoCISO is a multi-tenant SaaS platform that continuously collects evidence, evaluates controls, and maintains an ISO 27001 compliance posture for your organisation. This page describes the high-level system design for developers and security engineers integrating with or extending the platform.

System overview

The platform is composed of four main layers: data ingestion, analysis, the compliance engine, and the reporting surface.

flowchart TB
subgraph Ingestion["Data Ingestion"]
  direction LR
  API["Public REST API"]
  EXT["Browser Extension"]
  JOBS["Background Jobs"]
end

subgraph Analysis["Analysis Engine"]
  direction LR
  AI["AI / LLM Layer"]
  MONITOR["Continuous Monitor"]
  VULN["Vuln Scanner"]
end

subgraph Compliance["ISO 27001 Engine"]
  direction LR
  CTRL["Control Evaluation"]
  RISK["Risk Register"]
  EVIDENCE["Evidence Store"]
end

subgraph Output["Reporting & Alerts"]
  direction LR
  CONSOLE["Web Console"]
  MAIL["Email Alerts"]
  EXPORT["PDF / SBOM Export"]
end

Ingestion --> Analysis
Analysis  --> Compliance
Compliance --> Output
High-level platform layers and data flows.

Authentication flow

Every API request passes through JWKS-backed JWT validation before reaching business logic. The diagram below traces a typical authenticated API call.

sequenceDiagram
actor Client
participant API as AutoCISO API
participant Auth0
participant JWKS as JWKS Endpoint
participant DB as MongoDB

Client->>API: POST /api/v1/sscs/sboms/upload<br/>Authorization: Bearer <jwt>
API->>JWKS: Fetch public keys (cached 5 min)
JWKS-->>API: RS256 public key set
API->>API: Validate signature, exp, aud, org_id
alt Token invalid
  API-->>Client: 401 Unauthorized
end
API->>DB: Verify org membership
alt Not a member
  API-->>Client: 403 Forbidden
end
API->>DB: Write SBOM record
API-->>Client: 201 Created { data: { id, componentCount } }
JWT validation sequence for an API request.

SBOM ingestion pipeline

After an SBOM is uploaded, it passes through an asynchronous analysis pipeline before vulnerability data appears in the console.

flowchart LR
UPLOAD["Upload
POST /sscs/sboms/upload"] --> STORE["Store raw file
in S3"]
STORE --> PARSE["Parse
CycloneDX / SPDX"]
PARSE --> MATCH["Match components
vs CVE / RHSA feeds"]
MATCH --> SCORE["CVSS scoring
& severity triage"]
SCORE --> PERSIST["Persist findings
to MongoDB"]
PERSIST --> NOTIFY["Notify via
email / console"]

style UPLOAD  fill:#2563EB,color:#fff
style NOTIFY  fill:#059669,color:#fff
Asynchronous SBOM analysis pipeline.

Continuous monitoring

The monitoring scheduler wakes up on a configurable cadence, runs collectors against each connected data source, and flags controls that have gone stale.

stateDiagram-v2
[*] --> Idle
Idle --> Running : cron tick (hourly)

state Running {
  [*] --> FetchControls
  FetchControls --> RunCollectors
  RunCollectors --> EvaluateStaleness
  EvaluateStaleness --> PersistResults
  PersistResults --> SendAlerts : stale controls found
  PersistResults --> [*]      : all controls fresh
  SendAlerts --> [*]
}

Running --> Idle : done
Running --> Error : collector panic
Error --> Idle   : backoff + retry
Continuous monitoring scheduler loop.

Multi-tenancy model

Each organisation is isolated at the data layer. All queries are scoped by orgId derived from the verified JWT — never from a client-supplied header.

erDiagram
ORGANISATION {
  string id PK
  string name
  string plan
}
USER {
  string id PK
  string auth0Id
  string orgId FK
  string role
}
ASSET {
  string id PK
  string orgId FK
  string name
  string type
}
SBOM {
  string id PK
  string orgId FK
  string assetId FK
  string format
  int componentCount
}
FINDING {
  string id PK
  string orgId FK
  string sbomId FK
  string cveId
  string severity
}

ORGANISATION ||--o{ USER    : "has members"
ORGANISATION ||--o{ ASSET   : "owns"
ASSET        ||--o{ SBOM    : "has SBOMs"
SBOM         ||--o{ FINDING : "generates"
Tenant isolation model — every query is scoped by verified org_id.

Compliance evidence lifecycle

Evidence collected automatically or submitted manually flows through a review queue before being linked to an ISO 27001 control.

flowchart TD
A([Evidence collected
or uploaded]) --> B{Source?}
B -->|Automated collector| C[Auto-tagged
with control ID]
B -->|Manual upload| D[Queued for
reviewer tagging]
C --> E[Review Queue]
D --> E
E --> F{Reviewer
decision}
F -->|Accepted| G[Linked to
ISO control]
F -->|Rejected| H[Returned with
comment]
G --> I[Control status
recalculated]
H --> A

style A fill:#2563EB,color:#fff
style G fill:#059669,color:#fff
style H fill:#DC2626,color:#fff
Evidence lifecycle from collection to control linkage.

Next steps

Last reviewed: 2026-05-26

Was this page helpful?

Esc