What isops.ai does
The reference explanation of the whole platform: cloud posture scanning, control mapping, the AI copilot, the surrounding GRC workspace, audit reporting, and how it runs.
What isops.ai is
isops.ai is a compliance and security-posture platform for teams running on AWS. It reads your AWS accounts on a schedule you control, turns what it finds into control evidence against ISO 27001 and SOC 2, and gives you the surrounding GRC workflow — risk, policies, vendors, people, incidents, audits — in the same place.
It is built around one idea: posture should come from what your cloud actually looks like right now, not from a spreadsheet someone updated last quarter. Everything on this page traces back to that read-only inventory or to the records your team keeps alongside it.
What it is
- Scheduled AWS posture assessment
- Automated control evidence
- A working ISMS you can operate
- An audit-preparation workspace
- Self-hostable
What it is not
- A certification body — an accredited auditor still certifies you
- An agent installed in your workloads — it is read-only API access
- A replacement for your own security judgement
- A tool that writes to your AWS accounts without explicit, per-action human approval
The loop
Six steps, repeating on a schedule with two human-initiated checkpoints.
Connect
Deploy a read-only IAM role; paste the ARN. No agents, no write permissions.
Scan
12 scanners sweep IAM, storage, compute, data, network, logging and containers.
Map
Each finding is attached to the ISO 27001 and SOC 2 controls it bears on.
Remediate
The copilot drafts a fix; an admin reviews and explicitly confirms it.
Evidence
Passing checks become timestamped, control-linked evidence records.
Report
Export an audit pack, publish a trust center, or open an auditor portal.
Steps 1–3 and 5 run on a schedule; 4 and 6 are human-initiated.
Cloud posture scanning
Scanners are read-only boto3 collectors. Each returns findings with a severity — CRITICAL / HIGH / MEDIUM / LOW — and the ISO and SOC 2 controls it maps to. New scanners implement a single BaseScanner interface.
| Scanner | What it looks at |
|---|---|
| IAM | Users, roles, policies, MFA coverage, key age, privilege breadth |
| S3 | Public access, encryption, versioning, logging, bucket policy |
| EC2 | Instances, security groups, EBS encryption, unattached volumes |
| RDS | Encryption, public accessibility, backup retention, deletion protection |
| Lambda | Runtimes, execution-role scope, environment-variable exposure |
| Secrets Manager | Secret inventory, rotation configuration |
| GuardDuty | Detector coverage per region, active findings |
| Containers (EKS / ECS) | Cluster configuration, task and pod-level exposure |
| VPC | Network exposure, flow logs, routing and subnet layout |
| CloudTrail | Trail coverage per region, log-file validation |
| AWS Config | Recorder coverage and delivery |
| Drift | Change detected between scans against the previous baseline |
Cost signals
Alongside security findings, the platform surfaces cost waste — for example unattached EBS volumes — with an estimated monthly figure, because the same read-only inventory answers both questions.
Infrastructure discovery
A separate pass builds a topology of the account — resources and the relationships between them — rendered as a diagram and exportable. This feeds Discovery Intelligence, covered under the AI copilot below.
Frameworks and control mapping
ISO/IEC 27001:2022 — the full Annex A catalogue: 93 controls (37 Organizational, 8 People, 14 Physical, 34 Technological). 21 are scanner-checked, meaning isops can verify them directly from your AWS configuration on each scan. The rest are tracked as manual controls, satisfied with evidence, policies and records captured in the platform.
ISO/IEC 42001:2023 — the AI management system standard: all 38 Annex A controls across nine families. 3 of the 38 can be partially evidenced by scanning; the rest are management-system controls satisfied with assessments, owners and records kept in the platform.
SOC 2 Type II — 28 Trust Services Criteria controls mapped to the same finding set.
Additional reference mappings the platform tracks alongside these: GDPR, HIPAA, PCI DSS, NIST 800-53 and CIS Controls as control-mapping references, plus NIS2 and DORA requirement tracking.
Control states
| State | Meaning |
|---|---|
| Verified | isops checked this against live cloud configuration and it passed |
| Failing | isops checked it and found a gap; linked findings explain what |
| Not assessed | isops cannot verify this automatically — it needs manual evidence |
The denominator is always all 93 controls. A control with no automated check sits in Not assessed until someone attaches evidence — it is never quietly excluded to make the number look better.
Control mapping is editable: teams adjust which findings satisfy which control, and the mapping is versioned.
The AI copilot
Optional. The platform runs fully without an AI provider; you lose the reasoning layer, not the scanning, mapping or evidence.
Discovery Intelligence
A written narrative over the discovered topology and scan results: what this account actually is, how the pieces connect, where the risk concentrates. Grounded in scan data, not free-form generation.
Remediation drafting
For a finding, the copilot proposes a fix: the reasoning, the concrete AWS CLI steps, and a Terraform snippet where one applies.
Guardrails
- Drafted commands are parsed and executed as an argument vector, never through a shell.
- Only aws invocations are permitted; shell control characters are rejected outright.
- Execution requires an admin role and an explicit per-action confirmation.
- Every execution is written to the audit log with the actor who authorised it.
- Nothing runs automatically. There is no autonomous-remediation mode.
Provider-agnostic: Anthropic, OpenAI, or AWS Bedrock. Keys are encrypted at rest and are never returned by the API.
The GRC workspace
The modules that cover the roughly 72 controls no cloud scanner can answer.
See Module reference for the full list of screens and the artefact each one produces.
Module reference
Every screen in the platform, grouped by the question it answers. Each entry names the artefact it produces, because that is what an auditor is eventually handed.
Group 1 — What do I have, and who can reach it?
Infrastructure
A relationship graph of the AWS estate: resources, and what reaches what.
You do: browse the topology as a flow map, resource list or inventory; switch layout (hierarchy, organic, tree, circle); scope the view to all resources, ISO-relevant, production, internet-exposed or those carrying findings; overlay architecture, compliance, risk or evidence.
It produces: an asset inventory and access-path evidence for A.5.9 (inventory of information and other associated assets) and A.5.18 (access rights).
Discovery Intelligence
A written analysis of the graph, generated from the scan rather than typed by a person.
You do: read the narrative, open the categorised signals — critical, orphans, untagged, public — and jump from any signal to that resource on the map.
It produces: a prioritised cleanup list, including blast-radius hot spots that name how many downstream resources depend on a single one.
Findings
Live issues from the scanners, grouped so they can be worked.
You do: group by issue, scanner, category or region, or turn grouping off; filter by severity; expand any group to its individual resources.
It produces: control-mapped findings — each carries its Annex A control identifiers and an estimated time to remediate.
Limits: around 48 checks across 12 scanners. This is not a breadth play; open-source scanners cover far more individual checks.
Scans and Schedules
Scan runs and their recurrence.
You do: run a scan, review previous runs, and schedule recurring scans.
It produces: a timestamped scan history — every other screen states which scan it is grounded in.
Limits: discovery is scan-based. Each scan replaces the previous graph.
Monitoring
Change detection between scans.
You do: review the event feed, resolve events individually or in bulk, and ingest events from outside the platform.
It produces: a record of configuration change over time.
Assets
The IT asset register the standard expects, alongside the cloud graph.
You do: maintain assets; AWS resources import automatically.
It produces: the asset inventory for A.5.9.
Group 2 — What does the standard require of me?
Compliance
Control-by-control status per framework.
You do: switch framework, browse the full control catalogue, and filter to passing, failing or not assessed.
It produces: the control status an auditor reviews — stated as passing, failing and not assessed, with all controls in the denominator. A control with no automated check is never counted as a pass.
Control Map
Which findings, evidence and policies satisfy which control.
You do: adjust the mapping per framework.
It produces: a versioned mapping from your evidence to each framework's controls.
Risk Register
The risk register, seeded from what the scanners find.
You do: review risks scored on likelihood and impact, set treatment and owner, work the list or the heatmap, and add risks by hand.
It produces: a scored, owned risk register with treatment decisions — the artefact behind Clause 6.1 and A.5.x.
Readiness
Audit-preparation checklists per framework.
You do: seed the baseline checklist for ISO 27001:2022 or SOC 2, then work tasks to done.
It produces: a gap list showing what is still missing before an audit.
Policies
The policy set, with approvals.
You do: start from 31 built-in templates or write your own; send for review, approve, and track versions. Policies can be backed by a git repository, so the set is reviewed and versioned like source.
It produces: an approved, versioned policy pack with review history.
Group 3 — What will the auditor ask to see?
Evidence
The evidence library, most of it collected without anyone typing.
You do: filter by framework, type (scan, manual, document, screenshot) and status (active, expiring soon, expired); auto-collect from the latest scan; attach anything else by hand.
It produces: timestamped evidence records linked to a control, each carrying the scan it came from and whether it was auto-linked or added manually.
Incidents
Security incident records.
You do: record incidents, classify them, and track them to an outcome.
It produces: the incident history required by A.5.24 through A.5.28.
CAPA
Corrective and preventive actions, tracked to closure.
You do: raise actions from an audit, an incident, a risk, monitoring or an external source; work them through open, in progress, implemented, verified and closed, as a list or a kanban.
It produces: the corrective-action record an auditor asks for, traceable back to what raised it.
Internal Audit and Audit Programme
The internal audit cycle.
You do: plan the programme, record audits, and track findings to closure.
It produces: the internal audit records for Clause 9.2.
Management Review
The recurring leadership review.
You do: record each review, its inputs and its decisions.
It produces: the management review minutes required by Clause 9.3.
Access Reviews
Periodic entitlement review campaigns.
You do: open a review with a scope, reviewer and due date, then work its entries.
It produces: a reviewer-attested access review — the artefact for A.5.18.
People and Training
The people register and security-awareness records.
You do: maintain employees; assign training individually or in bulk and track completion.
It produces: the competence and awareness records for A.6.3.
Vendors
Third-party risk.
You do: register vendors, assess them, and set a risk tier and review date.
It produces: the supplier assessment records for A.5.19 through A.5.22. Vendors that have not been assessed are shown as not assessed, never as low risk.
Penetration Tests
Engagement records.
You do: record tests and track their findings to remediation.
It produces: the penetration-test evidence buyers and auditors ask for.
Reports
Generated PDFs.
You do: generate a compliance report, a risk assessment, an executive summary or an evidence package.
It produces: audit-ready PDFs. Each states the scan it is grounded in, and recomputes its figures at generation time so a report cannot disagree with the screen.
Audit Log
The trail of platform activity.
You do: review who did what, and when.
It produces: the activity record for A.8.15, including who authorised each remediation.
Group 4 — How do I show it to people outside?
Trust Center
A public page presenting your control posture.
You do: configure what is shown, then publish.
It produces: a shareable page describing automated control posture — labelled as posture, never as a certification.
Auditor Portal
Scoped, token-based access for an external auditor.
You do: issue access; the auditor signs in to their own view.
It produces: direct auditor access to controls, evidence, policies, incident summaries and audit reports per framework — without provisioning them a full account or emailing screenshots.
Questionnaires
Security questionnaire answering.
You do: upload a questionnaire; the copilot parses it and drafts answers from your own evidence.
It produces: draft answers with citations back to the evidence they came from.
Limits: drafts. A person reviews and sends.
Group 5 — How does it fit, and can I trust it?
Integrations
Connections to the tools already in use.
You do: connect GitHub, GitLab, Jira, Okta, Slack or Google Workspace, and send outbound events by webhook.
It produces: evidence from outside AWS, and findings turned into tickets in the tracker the team already uses.
Remediation
Fixes for findings, gated on a person.
You do: review a drafted fix, then approve it explicitly.
It produces: an execution record naming who authorised it.
Limits: commands are parsed and run as an argument vector, never through a shell; only aws invocations are permitted; execution requires an admin role and an explicit per-action confirmation. Nothing runs automatically.
Notifications, Developers, Admin, Settings
Platform plumbing.
You do: manage notification rules and delivery, API keys and the REST API, users, roles and organisations, and platform configuration.
It produces: role-based access — admin (read and write), viewer (read-only, the default) and auditor (read-only, for external review) — plus scoped API keys for your own automation.
The ISO Journey
A guided certification workflow: instead of a wall of 93 controls, it sequences certification into stages, shows what is done and what is next, and pulls in the evidence, policies and risks already captured elsewhere in the platform. Aimed at teams with no dedicated compliance function going through this for the first time.
Reporting and external sharing
Audit packs
Generated PDF reports covering posture, control status and evidence. Figures are recomputed at generation time from the same scoring source the dashboard uses, so a report can never disagree with the UI. Every report carries a disclaimer that it reflects automated control posture and is not a certification.
Trust center
A public-facing page presenting your control posture to prospects and customers, labelled as automated control posture rather than a certification.
Auditor portal
Scoped, token-based read access so an external auditor can review evidence directly without you provisioning them a full account or emailing screenshots.
Reports and exports
Scan results and findings as JSON and HTML for your own tooling.
Integrations and automation
- GitHub — repository security posture as an evidence source.
- GitLab — repository security posture as an evidence source.
- Jira — turn a finding into a tracked ticket in the workflow your team already uses.
- Okta — MFA coverage and identity-hygiene evidence.
- Slack — scan and finding notifications.
- Google Workspace — identity and account evidence.
- Webhooks — outbound events for anything else.
- Scheduled scans — recurring scans on AWS Lambda + EventBridge, with SNS or Slack notification on completion.
- Change monitoring — between scans, monitors watch for change and raise drift alerts when configuration moves away from the last known-good baseline.
- API and API keys — the platform's REST API with scoped keys for your own automation.
Security and architecture
This is a tool that reads your cloud and stores your compliance evidence, so its own security is part of the product.
- Read-only by default — AWS access is a read-only role (SecurityAudit plus scoped Describe* / List*). The only path that writes to your account is confirmed remediation, gated as described under the AI copilot above.
- Private by default — every API route requires authentication; a small explicit allowlist (health, login, public trust center, auditor portal) is the only exception. New routes are private unless deliberately opted out.
- Roles — admin (read and write), viewer (read-only, the default), auditor (read-only, for external review). Only admins can write or store cloud credentials.
- Tenant isolation — per-organisation scoping is enforced centrally at the data-access layer, not per-route, so a query cannot accidentally cross an organisation boundary.
- Secrets at rest — integration, SSO, webhook and AI-provider credentials are encrypted at rest and are never returned in API responses.
- Audit log — a full trail of platform actions, including who authorised each remediation.
- SSO — SAML/OIDC single sign-on; provisioned users land in the correct organisation with least-privilege defaults.
Stack — Python 3.11+, FastAPI, SQLAlchemy; a server-rendered dashboard; PDF generation in-process. No customer data leaves your deployment except calls to your configured AI provider, which you can turn off entirely.
Running it
Self-hosted — the deployment model that distinguishes isops: run it inside your own account, so cloud credentials and compliance evidence never leave your perimeter. Docker image and Compose file included.
Requirements — Python 3.11+; AWS credentials with read-only access; optionally an AI provider key (Anthropic, OpenAI or AWS Bedrock).
Interfaces — a web dashboard and a CLI.
# run a full scan isops scan --mode full # start the dashboard isops serve --port 8000 # map the topology isops discover --region eu-west-1 --format html
Deploy anywhere — isops is self-hosted, so it runs wherever you put it: your own AWS account, another cloud, or on-premises. Because it runs in your environment, cloud credentials and compliance evidence never leave your perimeter, and encryption at rest and in transit follow your deployment's configuration.
See it against your own AWS account.
30-minute demo, real account, first audit pack exported before we're done.