Automated evidence · 12 systems
Integrations
StandardOS connects read-only to the systems you already run, reads specific settings on a schedule, and turns each reading into an evidence entry against the Annex A control it supports. A passing check keeps that entry fresh. A failing one lets it expire, so the regression shows up in your notifications rather than in the audit.
Read-only APIs. No agent on anyone's laptop.
Every credential below is granted the permissions listed under it and nothing else, and every one of them is a read permission. Nothing StandardOS holds can change a setting, push a command or enrol a device. Device posture is read from the MDM you already run. Software on employees' machines is the loudest complaint about the incumbents and, in a European works council, a conversation about monitoring before it is a control. We do not have that conversation because we do not install anything.
Between them the 12 connections produce evidence for 52 of the 93 Annex A controls. Each control page names the reading behind it, and each card below links to the controls it covers.
Identity and directory
Microsoft Entra ID
How many people hold Global Administrator, whether guest accounts exist, whether multi-factor authentication is actually required to sign in, and whether Global Administrator is activated through PIM or held permanently.
What it checks
- Global administrators are few and accounted for
- External guest accounts are known
- Multi-factor authentication is required to sign in, by security defaults or an enabled conditional access policy
- Global Administrator is activated just in time, not held permanently
- Legacy authentication is blocked
- Directory roles are covered by an MFA policy
- A policy requires a compliant or joined device
- No enabled account has gone 90 days without signing in
- Application secrets and certificates live two years at most
- Guest invitations are restricted and guests see little
- Every administrator has a second factor registered
What the credential can see
- Directory.Read.All
- Policy.Read.All
- RoleManagement.Read.Directory
An app registration with application permissions, consented once by an administrator. Every permission is a read permission, so the credential cannot change anything in the tenant.
Evidence for
Okta
Your people, to keep the employee register current, the account states that mean somebody was never fully onboarded or never fully offboarded, and who holds Super Administrator.
What it checks
- Directory users are synchronized into the employee register, and anyone active here but gone from Okta is named
- No accounts are stuck part-way through joining
- Suspended accounts are accounted for
- Locked-out accounts are visible
- Super Administrator is held by few, named people
- No active account has gone 90 days without signing in
- Every super administrator has an active factor enrolled
- Administrator roles are held by few accounts
What the credential can see
- okta.users.read
- okta.roles.read
A read-only API token. It inherits the permissions of the administrator who creates it, so it is created as a read-only administrator, whose view includes who holds which admin role.
Evidence for
Google Workspace
Your people, to keep the employee register current, then two-step verification across the domain and who holds super administrator.
What it checks
- Directory users are synchronized into the employee register, and anyone active here but gone from Workspace is named
- Two-step verification is enrolled across the domain
- Super administrators are few, and all use two-step verification
- Suspended accounts are accounted for
- No active account has gone 90 days without signing in
- Two-step verification is enforced, not only enrolled
- Administrator roles are held by few accounts
What the credential can see
- https://www.googleapis.com/auth/admin.directory.user.readonly
A service account with domain-wide delegation for the single read-only directory scope, impersonating an administrator you name. A service account has no identity of its own in your directory, which is why Google requires that.
Evidence for
HR system
Personio
Your people from the HR system, to keep the employee register current: who is active, on leave or onboarding, and who has left.
What it checks
- Directory users are synchronized into the employee register, and any leaver in Personio still active here is named
- The HR system is the source of the employee register
- Every leaver carries a termination date
- No active employment has passed its contract end date
- Every active employment names a supervisor
What the credential can see
A custom integration under Marketplace, Connected integrations, with the single persons-read scope. Personio's API does not take a subdomain; the credential identifies the company, and nothing here writes to an HR record.
Evidence for
Cloud infrastructure
Amazon Web Services
Root account MFA and access keys, console users without MFA, access key age, the account password policy, the account-level S3 public access block, CloudTrail coverage, RDS encryption, backup retention and Multi-AZ, whether an AWS Config recorder is running, whether any EC2 instance runs in the default VPC, whether GuardDuty is enabled, who holds AdministratorAccess as a standing user, and whether each Systems Manager-managed instance carries a time-synchronisation service.
What it checks
- The root account has multi-factor authentication
- The root account has no access keys
- Everyone with console access uses multi-factor authentication
- Access keys have been rotated within 90 days
- A password policy is set on the account
- S3 public access is blocked for the whole account
- API activity is logged across every region
- Databases are encrypted at rest in the region you name
- Databases keep automated backups for at least a week
- Databases survive the loss of an availability zone
- Resource configuration is recorded continuously
- No workload runs in the default VPC
- Threat detection is switched on
- Full administrative access is held through roles, not standing users
- Managed instances run a time-synchronisation service
- No console password or access key sits unused for 90 days
- The root account is not used for daily work
- New EBS volumes are encrypted by default
- No security group opens SSH, RDP or a database port to the internet
- Every VPC records flow logs
- Customer-managed KMS keys rotate automatically
- IAM Access Analyzer watches for resources shared outside the account
- A backup plan is scheduled
- CloudWatch alarms carry an action that reaches someone
- Container images are scanned for known vulnerabilities on push
- AWS has a security contact to write to
- Capacity is watched
- A backup plan copies to another region or vault
What the credential can see
- arn:aws:iam::aws:policy/SecurityAudit
An IAM user holding one AWS-managed policy, SecurityAudit, which is read-only by construction. Naming the policy rather than listing actions means nobody assembles an over-broad policy by guessing, and you can verify it is the one AWS publishes.
Evidence for
Microsoft Azure
Storage accounts that allow public blob access or plain HTTP, SQL databases without transparent data encryption, their backup retention and zone redundancy, subscriptions whose activity log ships nowhere durable, network security groups that open SSH or RDP to the internet, storage lifecycle policies, and which Defender for Cloud plans are on.
What it checks
- Storage accounts do not allow public blob access
- Storage accounts require HTTPS and TLS 1.2 or later
- SQL databases are encrypted at rest
- SQL databases keep point-in-time backups for at least a week
- SQL databases survive the loss of an availability zone
- Subscription activity is logged somewhere durable
- No network security group opens SSH or RDP to the internet
- Storage accounts have a lifecycle policy for ageing data
- Defender for Cloud watches at least one resource type
- Key Vaults have soft delete and purge protection
- Storage accounts keep deleted blobs for a while
- SQL servers audit access
- No SQL server firewall rule admits the whole internet
- Network security groups record flow logs
- Defender for Cloud has a security contact to notify
- Azure Policy is assigned on every subscription
- A Recovery Services vault backs something up
What the credential can see
- Reader (Azure role, on each subscription in scope)
The Entra ID app registration, given the built-in Reader role on each subscription you want read. Reader is read-only by construction, assigned per subscription, and the same registration already connects Entra ID and Intune.
Evidence for
Google Cloud
Buckets readable by the public, Cloud SQL instances without TLS or open to the internet, service account keys past rotation, data-access audit logging per project, and firewall rules that open SSH or RDP to the world, and whether each Cloud SQL instance takes automated backups and runs across zones, and whether each bucket has a lifecycle rule.
What it checks
- No Cloud Storage bucket is readable by the public
- Cloud SQL instances require TLS and are not open to the internet
- Cloud SQL instances take automated backups
- Cloud SQL instances survive the loss of a zone
- Cloud Storage buckets have a lifecycle rule for ageing data
- Service account keys have been rotated within 90 days
- Data access audit logs are enabled across all services
- No firewall rule opens SSH or RDP to the internet
- Cloud Storage buckets keep object versions
- Cloud Storage buckets use uniform bucket-level access
- Cloud SQL instances are protected from deletion
- No person holds the basic Owner or Editor role
- No virtual machine has a public address
- Subnetworks record flow logs
- No project keeps the default auto-mode network
- Cloud KMS encryption keys rotate on a schedule
- Google has a security contact for every project
What the credential can see
- roles/iam.securityReviewer (project role)
A service account key with the built-in Security Reviewer role on each project in scope. The role is read-only by construction, and every active project the account can see is read; nothing here writes.
Evidence for
Source code
GitHub
Whether two-factor authentication is required, which repositories are public, whether default branches require review, how long Dependabot findings stay open, whether merges require passing status checks, and whether deployments go through a protected environment.
What it checks
- Two-factor authentication is required across the organization, or enabled on the account
- Source code repositories are private
- Default branches require review before merging
- Dependabot findings are fixed inside the remediation interval: 14 days for critical, 30 for high, 90 for medium, 180 for low
- Default branches require tests to pass before merging
- Production deployments go through a protected environment
- Every repository names its code owners and runs a workflow on change
- Nobody outside the organization can push without an agreement
What the credential can see
- read:org
- repo (read-only)
- security_events (read-only)
- read:user
A personal access token, classic or fine-grained, with the read-only scopes listed. Every scope except repo is optional: a check that needs one it was not given says which is missing rather than reporting a failure.
Evidence for
Vulnerability management
Snyk
Open issues measured against your remediation intervals, whether every project is actually being scanned, and whether any project's last test is too old to mean anything.
What it checks
- Open findings are fixed inside the remediation interval: 14 days for critical, 30 for high, 90 for medium, 180 for low
- Every project has been tested, so a project with no findings is one that was scanned rather than one that was skipped
- Every project has been tested in the last 30 days
- No secret is committed in a scanned repository
- Ignored high and critical issues are decided, not forgotten
- Pull requests are tested before they merge
What the credential can see
An API token from an account holding the Viewer role on the organization. Nothing here writes.
Evidence for
Managed devices
Kandji
Disk encryption and screen lock across your Apple fleet, and which devices have stopped checking in. Read from the MDM you already run, with no agent of ours anywhere.
What it checks
- Managed devices are encrypted at rest
- Managed devices lock when unattended
- Managed devices have checked in within 30 days
- Managed Macs have a recovery lock or firmware password
- Managed devices are supervised, so management cannot be removed
- Managed Macs carry no more than one local administrator
What the credential can see
- Device List (read)
- Device Details (read)
An API token scoped in Kandji's own settings to the two device read permissions. Nothing here writes.
Evidence for
Jamf Pro
FileVault, screen lock and Gatekeeper across your Mac fleet, and which devices have stopped checking in. Read from the MDM you already run, with no agent of ours anywhere.
What it checks
- Managed devices are encrypted at rest, counting a Mac as encrypted only when every account on it is
- Managed devices lock when unattended
- Managed devices run endpoint protection, read from Gatekeeper
- Managed devices have checked in within 30 days
- Managed Macs run the application firewall
- No managed Mac logs in automatically at boot
- System Integrity Protection and full secure boot are on
What the credential can see
- Read Computers
- Read Computer Inventory Collection
An API client with an API role holding exactly two read privileges, exchanged for a short-lived token. Not the Classic API's username and password, which would be a credential that can also wipe a laptop.
Evidence for
Microsoft Intune
Disk encryption across your managed devices and which have stopped syncing. The same app registration as Entra ID, with one more read permission.
What it checks
- Managed devices are encrypted at rest
- Managed devices have checked in within 30 days
- Managed devices meet their compliance policies
- No managed device is jailbroken or rooted
- A threat defense partner reports every managed device as secure
What the credential can see
- DeviceManagementManagedDevices.Read.All
The Entra ID app registration with one further application permission, consented once. A customer who has connected Entra adds the permission and connects this with the same client ID and secret.
Evidence for
How a reading becomes evidence
1. You connect, and the credential is checked before it is kept
The credential is tried against the vendor first. If it works, it is stored where no browser session can read it, and the first run happens immediately so you see results before you leave the page.
2. Every check runs daily and keeps one evidence entry
A passing check extends the entry's validity. A failing check pulls it back to today, so it expires the way a lapsed certificate does and appears in the same place. A check that could not read what it needed says so, and says which permission to grant, rather than reporting a failure it did not observe.
3. A pass that turns into a fail emails your administrators
Once, when it flips. A setting that was right last night and is wrong this morning is the one event worth an email; a setting that has been wrong for a month is already in your notifications.
What is not integrated
The question a feature-count comparison is really asking. Here is the answer, so you do not have to find it out after signing up.
An agent on anyone's laptop
Deliberately, and permanently. Everything about a device is read from the MDM you already run. Endpoint agents are the loudest complaint about the incumbents, and in a European works council they are a conversation about monitoring software before they are a control.
Other HR systems
Personio is read; BambooHR, HiBob, Workday and the rest are not. For a company whose people live in Okta or Google Workspace first, those keep the register current instead.
Ticketing, chat and logging platforms
Incident and change records are kept in StandardOS itself, on its own hash chain. Nothing is read from Jira, Slack or a SIEM.
Connected in minutes, read every night
Each connection is a form with the fields above and nothing else. The export your auditor receives is organised by Annex A reference, and every automated entry in it names the system it was read from and the day it was read.
Permission names are quoted as each vendor spells them, so you can match them against the vendor's own console when you grant them.