Compliance
See exactly which regulations you're ready for, which requirements are holding you back, and prove it with a dated evidence pack - without re-mapping the same control for every framework by hand.
Compliance
The Compliance screen answers the question every audit eventually asks: "Which regulations are we actually ready for, and what's still open?" Instead of a separate checklist per regulation, it evaluates a shared set of requirements once and maps the result onto every framework that cites them - so fixing one gap can close it in NIS2, ISO 27001 and DORA at the same time.
What You Can Achieve
See readiness per regulation, honestly
A readiness percentage per framework built from real tenant data, not a self-graded checklist. 'Not evaluated' means no data yet - it is never counted as a pass.
Fix once, close gaps everywhere
One requirement - say, an accountable owner on every AI agent - can be cited by articles in the EU AI Act, KRiBSI, and ISO/IEC 42001 at once. Fix it, and all three move.
Know what to work on next
A single deduplicated worklist, worst status first, ranked by how many articles in your scope each fix unlocks - not fourteen separate framework checklists to reconcile by hand.
Hand an auditor a dated document
Weekly automatic snapshots plus on-demand ones, and a per-framework evidence pack export, so 'what was our status on this date' has a real answer.
Requirements, Frameworks, Articles
The screen is built from three layers, and understanding them is the key to reading it correctly:
- Requirement - something your organization actually does or measures, e.g. "every AI agent has an accountable person," "activity logs are retained for six months," "restricted data types stay unreachable," or "sign-ins are covered by Conditional Access." There are 14 requirements. 10 are measured live from your tenant data by an evaluator that runs continuously; 4 are manual - an AI impact assessment, an AI usage policy and register, an incident response and reporting procedure, and risk management documentation - and are satisfied by an attestation the compliance officer records.
- Framework - a regulation or standard, such as GDPR or ISO/IEC 27001:2022.
- Article - a citable control inside a framework (a paragraph, an Annex A control, a criterion). Each article names the requirements that satisfy it, and its status is always the worst status among those requirements.
Because one requirement is typically cited by articles across many frameworks, a single fix is done once and counted everywhere it applies - you never re-prove the same control fourteen different ways.
Frameworks Available
Eleven frameworks are supported, grouped by region in the framework picker:
- European Union - EU AI Act, NIS2 Directive, GDPR, DORA
- Poland - the Polish act on the national cybersecurity system (KSC), the Polish AI act (KRiBSI)
- United States - SOC 2 (Trust Services Criteria), NIST Cybersecurity Framework 2.0, HIPAA Security Rule
- International standards - ISO/IEC 42001:2023 (AI management system), ISO/IEC 27001:2022 (information security management system)
Statuses
Every requirement and every article carries one of four statuses, deliberately conservative because a verdict shown to an auditor must under-promise:
- Met - the requirement's measurable condition holds today.
- At risk - the requirement is in use but its condition only partially holds.
- Not met - the requirement's condition clearly fails.
- Not evaluated - honest, not a failure. Either there's no data yet (no AI agents discovered, no restricted data types declared, no Intune compliance data, no sign-in activity observed) or the requirement is manual and hasn't been attested yet.
First Visit: Which Regulations Apply to You?
Until you declare your own scope, a default set is in scope (EU AI Act, NIS2, GDPR, ISO 27001) and the overview says so. Manage frameworks opens the picker: framework cards grouped by region, each with its name, description, who it typically applies to, its article count, a readiness bar and a View articles link into the detail view, so you can inspect a regulation before adopting it. Your selection is per tenant and can be changed anytime; on the demo tenant the picker works the same way.
Frameworks you don't select keep being evaluated in the background and appear in an Also covered strip on the overview with their own readiness percentage - so you can see how close you already are on, say, ISO 27001, before formally adopting it.
The Overview
Once frameworks are selected, four tiles at the top count the requirements in your scope - Met, At risk, Not met, Not evaluated - and clicking one filters the worklist below to that status.
Your frameworks lists each selected framework with a segmented readiness bar across its articles, a readiness percentage (met divided by met + at risk + not met), its top open gap, and, once a snapshot exists, a chip such as "+2 met since <date>" showing the change since the latest snapshot.
What to fix is the deduplicated worklist: every open requirement appears once, worst status first, then ordered by how many articles in your scope it unlocks - each with chips naming the frameworks it satisfies, like "NIS2 ×2", "DORA", "ISO 27001". Requirements that are already met or not yet evaluated sit collapsed below, out of the way.
Framework Detail
Click a framework to see its articles in the regulation's own order - each with its reference, its status, and chips for every requirement it cites. Articles whose status changed since the last snapshot are marked with what they changed from.
Three actions live here: Print, scoped to just this framework; Export evidence pack, a JSON document limited to this framework's articles (the same document the API serves at GET /api/v1/evidence/agents?framework=<key>); and Add to my frameworks, shown only when the framework isn't in your selected scope yet.
The Requirement Panel
Click any requirement - from the worklist or from a framework's article list - to open its panel:
- The verdict and why, in plain language, plus a progress bar where one makes sense (e.g. "12 of 15 agents have an accountable person").
- Next-step links into the screens where the underlying data lives - Agents, Sensitive info, Applications, Activity logs, Anomalies, Sensitivity labels, Devices, Users, Locations, Alerting, Integrations.
- What this asks of you - the plain-language duty behind the requirement.
- How 1Security checks it - the exact measurement.
- The numbers behind the verdict - the metrics the evaluator computed.
- Evidence 1Security holds - the product capabilities that back the requirement, shown for auditors.
- Satisfies N articles - every article across every framework this requirement satisfies, your selected frameworks first, others marked "not in your scope."
For the 4 manual requirements, the panel also carries the attestation form: status (In place, In progress, Not applicable), owner, next review date, an evidence link, and a note. One attestation applies to every framework that cites the requirement, and is kept in snapshots and evidence packs. Measured requirements can't be attested - the data decides, not a person.
How the 10 Measured Requirements Are Checked
| Requirement | What is measured | Met when |
|---|---|---|
| Accountable person per AI agent | Agents with a native owner/sponsor, or a person assigned in 1Security | All agents covered. Some covered = At risk, none = Not met. |
| Activity logs retained six months | Whether activity logs are ingested and retained (1Security keeps them for the life of the subscription), plus how much history has accumulated against the 183-day floor | Logs are ingested. No logs at all = Not met. |
| Instructions captured per AI agent | Agents discovered and how many expose instructions 1Security could capture | Agents discovered with at least some instructions captured. Agents discovered but nothing captured at all = At risk. |
| Restricted data types stay unreachable | Restricted sensitive data types with no reachable files, users, apps, agents or emails | No banned type is reachable. Any reachable = At risk. No restrictions declared = Not evaluated. |
| Third-party apps inventoried with their reach | Whether the application inventory exists: apps discovered with their reach and permission lineage (a banned type reachable through an app is judged on the restricted-data requirement) | Apps discovered. None discovered yet = Not evaluated. |
| Activity monitoring | Whether logs are still being ingested, and whether any critical anomaly episode has sat open over a week | Ingestion within 72 hours and no stale critical episode. Over 72 hours or a stale critical episode = At risk; over 30 days with no ingestion = Not met. |
| Restricted files carry a protecting label | Files of banned types under a sensitivity label that encrypts | All such files labeled. Some labeled = At risk, none = Not met. |
| Devices managed and compliant | Intune compliance state of enabled Entra devices | No non-compliant devices among those with a known state. Without Intune data = Not evaluated. |
| No dormant accounts left enabled | Enabled accounts with no sign-in for 90 days | None dormant. Up to 30% of enabled accounts dormant = At risk; more = Not met. |
| Sign-ins covered by Conditional Access | Sign-ins with no Conditional Access policy applied | None uncovered. 90%+ coverage = At risk; less = Not met. |
Snapshots
Snapshots are dated captures of the whole status document - taken automatically every Monday, and on demand with Take snapshot. The snapshots table lists each one with its counts and a JSON download, and both the overview and the framework view show what changed since the latest snapshot, so "what changed since last month" has a direct answer instead of a manual diff.
Access and API
Reading the screen requires the Compliance section's view access in the admin access matrix; taking a snapshot, changing selected frameworks, or recording an attestation requires write access there.
GET /api/v1/compliance/status and GET /api/v1/compliance/snapshots (scope evidence:read) return the same status document and snapshot history the screen renders. GET /api/v1/evidence/agents?framework=<key> returns the per-framework evidence pack. The same data is also available as MCP tools.
Alerting
Every notification origin on one screen - trends, activities, anomalies and automations - with a notification log of what was actually sent, to whom and why something was withheld, overrides down to a single user, and mail that leaves from your own domain.
Devices
See every device touching your data - including the ones Microsoft never told you about - and answer whether your information is being accessed from machines you don't control.