This is week eight of the SwarmCraft workflow replacement case-study series, and it is the first time we have deliberately crossed a line drawn in the previous seven.
The first seven case studies used the bounded pattern that Fast Start now makes explicit: keep the trusted system of record and replace one workflow around it. That remains a useful default for an HRIS, LMS, CRM, accounting platform, or document repository when the awkward coordination layer is the real problem. It is not a universal ban on owning records.
Compliance creates a more interesting question.
For a small company working toward one standard, the compliance platform may not be the upstream source of truth at all. It often stores a structured representation of the company's own management system: its scope, risks, controls, owners, evidence, review dates, decisions, findings, and corrective actions.
If the system is describing your management system, why must you rent that system of record forever?
Week eight tested the smallest credible version of an alternative. SwarmCraft used an AI build agent to turn an ISO 27001 compliance-operations brief into a 41-ticket application with role-aware screens, workflow APIs, PostgreSQL persistence, immutable decision history, independent approval rules, evidence references, background-job foundations, integration boundaries, deployment contracts, and browser evidence.
It is not a finished Vanta replacement. It is something more useful for this experiment: a working proof of the minimum kernel a small company would need to own before the larger vision becomes credible.
If you want the category view first, start with Best compliance management software. If your current problem is duplication across a growing stack, read Why compliance workflow sprawl weakens accountability. This article is about the more provocative option: owning the narrow system that makes an ISO 27001 management system move.
The economics have changed
Vanta already covers a great deal of this territory. Its current pricing page describes automated evidence collection, continuous tests, policies, framework support, audit workflows, an auditor API, and trust-centre capabilities. It does not publish a fixed self-service price; buyers request personalised pricing.
That matters because this is not an argument that established compliance platforms forgot how compliance works. They are capable products with maintained integrations, framework content, support, auditor relationships, and years of accumulated edge cases.
The question is whether every small company needs to keep buying that complete product.
Vendr's Vanta pricing data, based on anonymised transactions rather than an official Vanta list price, reports an observed annual range of roughly $12,000 to $28,000 for a company with 1–50 employees and a single framework. At that range, three subscription years are $36,000 to $84,000 before implementation help, internal labour, or the independent audit.
That arithmetic is an economic envelope, not a promised saving. Owned software still has hosting, security, maintenance, monitoring, change-management, and opportunity costs. A broad multi-framework programme with frequent regulatory change can make a maintained platform the cheaper choice.
But a technically capable small company with a stable, single-framework scope can now ask a question that would have sounded irresponsible a few years ago:
Could we own a smaller system that matches how our company actually operates, and spend the subscription budget on the management system and independent assurance instead?
The external assurance cost does not disappear. Vanta's own ISO 27001 certification cost guide separates preparation and software choices from certification-body audit costs. Replacing a software subscription does not replace the independent auditor, the certification body, or the work required to operate an effective management system.
ISO 27001 is a better starting point than SOC 2
The International Organization for Standardization describes ISO/IEC 27001 as the requirements standard for an information security management system, adaptable to organisations of different sizes and needs. That management-system shape is exactly why it is a useful foundation for owned workflow software.
The company defines a scope. It understands interested parties and obligations. It assesses risks. It chooses treatments and controls. It operates those controls, checks whether they are effective, records nonconformities, takes corrective action, conducts internal audits, and reviews the system at management level.
That is not a one-off certification project. It is a recurring operating model.
SOC 2 could reuse parts of the same kernel later: ownership, evidence, recurring tests, independent review, findings, and immutable history. But SOC 2 has a different assurance context and was not implemented in this build. Week eight stays focused on ISO 27001.
The application also does not reproduce copyrighted ISO text. An owned system can store identifiers, company interpretations, mappings, and content the organisation is licensed to use. It should not turn a standards licence into an unauthorised public copy.
The smallest viable ISMS is a graph that generates work
A folder of policies is not an information security management system.
A useful ISMS is a connected model:
| From | Relationship | To |
|---|---|---|
| Business context | defines | ISMS scope and obligations |
| Risks | lead to | treatment decisions |
| Treatments | select and justify | organisational controls |
| Controls | govern | assets, suppliers, processes, and people |
| Auditable objects | generate | recurring work occurrences |
| Work occurrences | collect | evidence and exceptions |
| Independent decisions | produce | approval, rejection, or findings |
| Findings | generate | corrective actions |
| Metrics, audits, and actions | feed | management review |
Once those relationships exist as a domain model, much of compliance operations becomes mechanical.
Every item that must be checked—an access review, supplier assessment, risk treatment, backup test, policy review, internal audit action, security objective, or management-review input—becomes an auditable object. Its schedule creates a new occurrence. That occurrence appears on a Kanban board with an owner, checklist, due date, required evidence, reviewer, and escalation path.
The occurrence moves. The underlying requirement does not.
That distinction solves a common compliance tracking problem. A recurring review should not overwrite last quarter's evidence or reopen an old approval. It should create new work linked to the same control, risk, or obligation, preserving the complete sequence of what was due, what happened, who decided, and what changed.
This is the heart of the experiment: model the management system once, then let the model generate the work required to operate it.
Project stats
| Stat | Week 08 result |
|---|---|
| Implemented tickets | 41 |
| Final board state | 41 done / 0 open |
| Build runner | OpenAI Codex CLI |
| Agent requests | 41 |
| End-to-end driver runtime | 3h 18m |
| Build-lane runtime | 3h 15m |
| Tracked files | 217 |
| Tracked text lines | 26,358 |
| Test and spec files | 52 |
| PostgreSQL migrations | 7 |
| Browser scenarios | 14 passing |
| Target-system screenshots | 15 |
| SwarmCraft setup screenshots | 2 |
The final build manifest recorded all 41 selected tickets as done, with no open, blocked, or manual-review outcomes.
The repository is substantial, but the numbers need the same qualification as the product claim. They prove that an AI agent can create and exercise a production-shaped architectural spine. They do not prove that the application has already survived a certification audit, a penetration test, a disaster, or years of framework updates.
What we actually built
The build has two layers.
The first is a real persisted workflow kernel:
- organisations and compliance-framework records
- roles, capabilities, and server-side authorisation
- a workflow state machine from draft to review and decision
- explicit approval, rejection, and changes-requested outcomes
- independent-review enforcement that prevents self-approval
- append-only transitions, decisions, validation failures, and security audit events
- evidence references without forcing evidence binaries into the workflow database
- durable background-job foundations
- identity, controlled-document, object-storage, notification, and source-system adapter boundaries
The second is a broader set of deterministic ISO 27001 operating screens that demonstrates where that kernel can go: the overview, risk register, Statement of Applicability, controlled documents, assets, suppliers, findings, metrics, audit work board, history, and management review.
Those wider screens are domain and interaction prototypes. Several creation, export, and drafting controls are intentionally placeholders, and the full risk-to-control-to-occurrence graph is not yet persisted end to end.
That is the honest boundary. We did not build all of Vanta in one run. We built and tested the narrow vertical slice that makes an owned compliance system plausible.
The compliance review workflow
The application is shaped around five accountable roles.
| Role | Responsibility |
|---|---|
| ISMS manager | Maintains the operating view, assigns work, reviews controls, manages access, and approves eligible workflow items. |
| Control owner | Prepares control work, submits evidence, and responds when a reviewer asks for changes. |
| Risk owner | Owns risk decisions and treatment work rather than delegating risk acceptance to the software. |
| Internal auditor | Reviews independently, records findings, and reads the history needed to reconstruct a decision. |
| Management representative | Reviews management-system performance and records accountable management decisions. |
The intended ISO 27001 compliance review process follows this sequence:
- The organisation records its scope, framework, risks, treatments, organisational controls, owners, and review cadence.
- Each scheduled auditable object creates a fresh work occurrence instead of mutating the previous review.
- The occurrence enters the audit work board with its checklist, owner, due date, evidence requirements, and reviewer.
- The owner performs the work and links evidence from the system that owns it.
- Server-side validation checks completeness and role capability before accepting submission.
- An independent reviewer approves, rejects, or asks for changes. The owner cannot approve their own work.
- The workflow records the decision, reason, actor, time, transition, and evidence references in append-only history.
- Rejection or a failed control can generate a finding and corrective action without erasing the original result.
- Due dates, failed jobs, overdue work, and exceptions become visible operating queues rather than private reminders.
- Risks, audit outcomes, objectives, metrics, incidents, and corrective actions feed a prepared management-review packet.
AI can help classify evidence, suggest mappings, identify gaps, summarise a review packet, or draft an action. It cannot approve its own suggestion, accept a risk, declare a control effective, or claim certification.
The overview makes the management system operational
The overview brings programme state, open work, risk, review readiness, and recent activity into one operating surface.
This is deliberately not a badge that says “compliant.” A dashboard can show recorded state and unresolved work. Only the organisation and its independent assurance process can determine whether the management system is effective.
Risks and controls stay connected
The risk register demonstrates the structure needed to move from identified information-security risk to ownership and treatment.
The Statement of Applicability then makes control selection and justification visible.
The important design decision is to separate a framework requirement from an organisational control. A requirement can influence several controls. One control can satisfy several requirements. The company's control needs its own owner, implementation, evidence, review history, and effectiveness judgement.
A catalogue that collapses those concepts may look simpler, but it becomes difficult to explain why the company chose a control or how it operates in this particular context.
The audit board turns the model into work
The Kanban board is where the management system stops being documentation and starts behaving like operations.
Each card represents a specific occurrence, not the timeless control itself. A quarterly access review in July is different work from the review performed in April, even when both refer to the same organisational control.
That small modelling decision makes automation safer. The scheduler can create the next occurrence without modifying accepted evidence. The board can show what is overdue without pretending that an old completion covers a new period. Auditors can trace each decision back to the exact work package reviewed.
Decisions are evidence, not status labels
An approved workflow retains the actors, state changes, decision, and evidence trail.
Rejection is equally important. A trustworthy workflow must preserve negative outcomes instead of making failed work disappear from the queue.
The persistence layer treats transitions and decisions as append-only facts. The current workflow row is a projection for fast operational reading; it is not allowed to replace the history needed for assurance.
Authorisation is enforced at the workflow boundary
The control owner can reach the work required for their role.
The same user is denied access to restricted audit history.
This is more than hidden navigation. Protected API operations enforce capabilities on the server, and rejected attempts create security-audit evidence. The browser suite also exercises the inverse path: an ISMS manager can reach authorised management surfaces while being denied capabilities that belong to another role.
Independent review is enforced the same way. The interface cannot turn a self-approval into a valid decision by calling the endpoint directly.
Capabilities and current boundary
| Capability | Week 08 evidence | What remains |
|---|---|---|
| Identity and roles | OIDC/SAML adapter contracts, five seeded roles, capability-aware UI, server-side denials | Connect and harden the chosen production identity provider |
| Workflow decisions | Persisted state machine, approval, rejection, changes requested, no self-approval | Add policy configuration for different auditable-object types |
| Audit history | Append-only transitions, decisions, validation failures, and security events | Retention, export, signing, and external audit access policies |
| Evidence | Typed evidence references and object-storage adapter boundary | Production malware scanning, retention, legal hold, and connector implementation |
| ISO 27001 model | Organisation/framework foundation plus risk, SoA, finding, metric, and review interface patterns | Persist the full scope-risk-treatment-control-occurrence graph |
| Recurring work | Durable-job migration and job-run operating foundations | Generate all review occurrences from real schedules and calendars |
| Notifications | Email and Slack adapter boundaries | Production credentials, templates, escalation policy, and delivery reconciliation |
| Management review | Prepared management-review interaction pattern | Persist inputs, decisions, actions, attendance, and approved outputs |
| Delivery | Containers, health contracts, CI structure, and runbooks | Threat modelling, load testing, backup restoration, operational ownership, and production assurance |
This table is why “AI built a Vanta replacement in three hours” would be the wrong headline. The build proves architecture, workflow mechanics, and delivery leverage. The remaining column is where a demonstration becomes a dependable company system.
Technology implemented
| Layer | Week 08 implementation |
|---|---|
| Browser application | React 19 and Vite with responsive, role-aware compliance operations screens |
| API | Node.js service with explicit authentication, authorisation, workflow, audit, and integration modules |
| Persistence | PostgreSQL with seven versioned Flyway migrations |
| Identity | OpenID Connect and SAML adapter contracts with deterministic authenticated test fixtures |
| Documents and evidence | Controlled-document and object-storage adapter boundaries with evidence references |
| Scheduling | Durable PostgreSQL-backed job records for recurring and retryable work |
| Notifications | Email and Slack notification boundaries |
| Assurance | Append-only workflow transitions, decisions, validation failures, and security-audit records |
| Delivery | Container definitions, health checks, CI contracts, deployment configuration, and operating runbooks |
| Verification | Unit and integration coverage plus Playwright system, security-smoke, and UI suites |
What the browser evidence proves
Three system-test scenarios, five security-smoke scenarios, and six UI scenarios passed: 14 browser scenarios in total.
The system suite exercises the overview, risk register, Statement of Applicability, audit board, approved and rejected decisions, audit history, and role denials. The security suite separately captures authorised and denied sessions, the audit board, and the responsive shell. Eleven stable system-test screenshots and four security screenshots were retained with the article.
This evidence proves that the implemented paths can be driven through a real browser against the deterministic test environment. It does not prove that every screen is backed by a complete production domain model or live external connector.
That distinction is part of the evidence, not a weakness to hide.
How SwarmCraft structured the build
The scenario created a 41-ticket ISO 27001 Compliance Operations project. The initial board covered foundations, identity and audit, workflow persistence and APIs, integration boundaries, operating screens, browser tests, CI, production configuration, and runbooks.
The board image is the initial implementation plan. The build manifest records the final outcome: 41 tickets selected, 41 completed, zero open, zero blocked, and zero manual-review outcomes.
The ordering matters. The agent did not begin with a glossy compliance dashboard. It established the database, capabilities, security audit, workflow state, immutable history, and adapter boundaries before finishing the wider operating experience and browser proof.
That is the more consequential AI capability. Generating screens is useful. Generating a coherent sequence of architectural work—and carrying it through persistence, denial paths, tests, delivery contracts, and documentation—is what changes the cost of owned software.
What stays a system of record
Owning this compliance application does not mean pulling every fact into it.
| Record | Appropriate owner |
|---|---|
| Employee identity and employment state | Identity provider or HR system |
| Cloud resources and configuration | Cloud platform and infrastructure-as-code repository |
| Source documents and approved policy files | Controlled document repository |
| Source code and change history | Version-control platform |
| Supplier contracts | Contract or document system |
| Security telemetry | Monitoring and security platforms |
| Certification decision and certificate | Independent certification body |
| Risks, control intent, recurring review work, evidence links, decisions, findings, and management actions | Owned ISMS workflow |
The compliance application stores why those source facts matter, when they must be reviewed, who reviewed them, what evidence was considered, what decision was made, and what happens next.
That is the narrow record worth considering as owned software.
What must be true before you retire the compliance platform
Do not cancel a compliance platform while its integrations, framework mappings, evidence collection, auditor access, trust-centre workflows, or update process still contain responsibilities nobody has mapped. Keep it as a temporary continuity boundary while the owned management system is shaped, tested, and assured.
The exit plan must account for the capabilities the subscription currently supplies:
- several frameworks and a maintained cross-framework control map
- a large catalogue of production integrations immediately
- rapid evidence collection across a changing technology estate
- established auditor collaboration and trust-centre workflows
- vendor-maintained framework updates and implementation guidance
- accountable software operations, security, and support for the owned system
- predictable commercial accountability for product support and availability
- an approved sequence for replacing, procuring, or dropping each capability
Vanta is not expensive because it forgot to build a Kanban board. The fee buys maintained scope, integrations, content, operations, support, and accumulated product knowledge. Those responsibilities do not disappear when the subscription ends; they become explicit ownership, specialist-provider, or assurance work.
The owned compliance system becomes ready for cutover when:
- the company is small and technically capable
- ISO 27001 is the primary framework
- the scope and integration surface are stable
- the management system is already understood
- current platform automation duplicates internal engineering sources
- a named owner can maintain the application and its security
- the three-to-five-year total cost is lower after hosting, maintenance, assurance, and change are included
- the company values a domain model shaped around how it actually manages risk
The smallest production MVP would not start by recreating every vendor integration. It would persist the management-system graph, generate auditable work, link evidence from existing sources, enforce independent decisions, retain immutable history, and prepare management review.
Run the owned and incumbent processes in parallel across a real review period, reconcile open work and evidence, test auditor access and recovery, and keep the old platform read-only until the organisation can reconstruct its decisions without it. Everything else should earn its place: own it, leave it with a suitable specialist, schedule it for later, or remove it because the management system does not need it.
If the current platform's hidden responsibilities or the migration boundary are not yet known, Deep Discovery can turn them into an evidence-led exit plan. For current alternatives and their different strengths during that transition, see Vanta alternatives.
What this says about AI-built software
The breakthrough is not that AI can generate a compliance dashboard.
The breakthrough is that an experienced operator can bring a deeply considered domain model, ask an AI agent to turn it into a sequenced implementation plan, and receive a tested software foundation quickly enough to change the build-versus-buy calculation.
That does not eliminate engineering judgement. It increases the value of it.
Someone still has to decide what the domain means, where authority lives, which actions require independent judgement, what evidence is trustworthy, how failure is handled, and what must never be automated. AI compresses the translation from those decisions into working software.
In this workflow, AI may:
- propose mappings between risks, treatments, requirements, and organisational controls
- classify incoming evidence and flag missing context
- draft review summaries and management-review inputs
- suggest which auditable objects are affected by a change
- prepare findings and corrective-action proposals
- explain anomalies and overdue work
It must not:
- accept risk for the organisation
- approve its own evidence assessment
- declare a control effective
- silently rewrite immutable history
- publish licensed standards content
- represent that the organisation is certified
Human accountability is not friction to automate away. It is part of the product.
What operator-builders should take from week eight
The first seven weeks showed that a company can preserve trusted records and own the workflow between them.
Week eight goes one step further.
For a small company with one well-understood standard, the compliance product's central record may be a model of the company's own management system. When that model is narrow, stable, and operated by a capable team, AI-assisted development can make ownership economically plausible.
The responsible path is not to declare victory after generating 41 tickets. It is to start with the kernel, make its authority boundaries explicit, validate the workflow under real operating conditions, and compare total cost over years rather than subscription price alone.
Keep identity in the identity provider. Keep documents in the controlled repository. Keep cloud facts in the cloud. Keep certification with the independent certification body.
Own the graph that explains how those facts become risk treatment, recurring work, evidence, independent decisions, findings, corrective actions, and management review.
The smallest viable ISMS is not a folder of policies. It is a graph that generates accountable work.
That is the week-eight experiment—and it changes the question from “Which compliance platform should we rent?” to “What is the smallest management system we are now capable of owning?”
Mobile evidence
The responsive proof is intentionally placed last because the captured page is long. It confirms that the operating shell, navigation, programme overview, status cards, and activity surfaces remain usable on a narrow screen rather than turning the owned system into a desktop-only compliance console.
Choose a discovery route
If interviews, source material, record ownership, controls, or migration need structured review, explore Deep Discovery. It can investigate whether to keep, integrate, migrate, or own records without presuming replacement is safe. Deep Discovery is currently available through a limited account-enabled rollout.
