Control frameworks for every layer
of the modern platform stack.
Platform-specific, practitioner-built. Each framework tells you how to design the control, where it breaks, what evidence it produces, and exactly what your auditor will test.
Built for how audit work actually happens.
Every control walks you through the same sequence an auditor walks through in the field — from understanding the risk, to designing the control, to collecting the evidence, to writing the test.
This control ensures the only way into your GitHub Organization is through your company’s central login system — the same system that gets disabled the moment an employee is terminated. Without it, someone could have their company email and laptop taken away on their last day but still log into GitHub using a password they set three years ago.
The building has one entrance with a badge reader connected to HR. When someone’s employment ends, facilities disables their badge in one place and they lose access everywhere. SSO enforcement is that single entrance — without it, employees could have personal keys cut from the master that still work even after their badge is deactivated.
Without SSO enforcement, terminated employees retain direct access to repositories containing financial application code and database migration scripts. GitHub specifically allows both SAML SSO and direct username/password authentication simultaneously unless enforcement is explicitly enabled — organizations that have configured SAML without enforcing it have the appearance of SSO governance with none of the access control.
The difference between Level 1 and Level 2 is one checkbox — “Require SAML SSO authentication.” Everything before that checkbox is setup; that checkbox is the control. Level 3 adds the detection layer so you know the moment someone turns it off.
You’re enabling the one setting that blocks all non-SSO login paths, then setting up an alert so you know immediately if it’s ever turned off.
- Navigate to Organization → Settings → Authentication security. If you are on GitHub Enterprise, also check Enterprise → Settings → Authentication security.
- Under “SAML single sign-on”: enter your IdP’s Sign-On URL and public certificate. Click “Test SAML configuration” and confirm a successful test before proceeding.
- Check “Require SAML SSO authentication for all members.” Members who have not yet authenticated via SSO will be removed from the organization after a grace period and must re-join through SSO.
- Navigate to Organization → Settings → Audit log → Log streaming and confirm streaming is active. Verify that org.disable_saml is included in the event stream.
- In your SIEM, create a detection rule: alert immediately on any event matching
action:org.disable_saml OR action:business.set_saml_disabled.
# Confirm SAML is enforced — not just enabled
gh api graphql -f query='query {
organization(login: "YOUR_ORG") {
samlIdentityProvider {
ssoUrl
issuer
}
requiresTwoFactorAuthentication
}
}'
# List all members WITHOUT a linked SAML identity
# These accounts can still log in without SSO
gh api orgs/YOUR_ORG/members --paginate \
-f filter=2fa_disabled \
--jq '.[] | .login'You need to prove two things: (1) SSO enforcement was turned on and set correctly at the beginning of the period, and (2) it was never turned off. The configuration screenshot proves the first. The audit log query proves the second.
| Evidence Item | Source / Method | What to Verify |
|---|---|---|
| SAML SSO configuration screenshot or API export | Org Settings → Authentication security | “Require SAML SSO authentication” is checked. IdP URL populated. Exemption list empty or documented. |
| Audit log — SSO disable events for the full audit period | API export or SIEM query | Zero org.disable_saml events returned. Any event requires documented justification and management sign-off. |
| Member list with SAML identity linkage | GraphQL API export | All active human members show a linked SAML identity (nameId populated). |
# Confirm SAML is enforced at the organization level
gh api graphql -f query='query {
organization(login: "YOUR_ORG") {
samlIdentityProvider { ssoUrl issuer }
}
}'
# Returns any event where SSO was disabled — should return empty
gh api orgs/YOUR_ORG/audit-log --paginate \
-f phrase="action:org.disable_saml" \
-f created="2025-01-01..2026-01-01" \
--jq '.[] | {actor, action, created_at}'The most common gap: the distinction between “SAML enabled” and “SAML enforced.” Always verify enforcement status, not just configuration. A second gap: the SSO exemption list — ask explicitly: “Pull the list of all accounts currently exempted from SSO enforcement and show me the business justification for each.”
Design testing confirms the control is correctly configured. Operating effectiveness testing confirms it remained correctly configured — and was never disabled — for the entire audit period. For SSO, operating effectiveness is binary: either the setting was on the whole time or it wasn’t.
- Request the GitHub Organization authentication security settings. Confirm “Require SAML SSO authentication” is enabled — not just “Enable SAML SSO.” These are two separate settings.
- Confirm the connected IdP is the organization’s corporate identity provider. Verify by checking the Sign-On URL against the known corporate IdP tenant.
- Run the GraphQL query. For every active human member, confirm a SAML nameId is populated. Document the count with and without linked identities.
- Request the SSO exemption list. For each exemption, confirm there is a dated business justification and approving authority signature.
- Run the audit log query with the full audit period date range. The complete population is every org.disable_saml and business.set_saml_disabled event logged during the period.
- If the query returns zero events: document “no SSO disable events identified for the period [date range]. Control operated as designed.” This is sufficient ToE evidence.
- If the query returns any events: for each event, obtain (a) the dated business justification, (b) confirmation that SSO was re-enabled within SLA, and (c) management sign-off.
This is one of the few GitHub controls where the ToE population is binary — either the setting was disabled during the period or it was not. Your evidence memo should explicitly state: “Reviewed complete audit log; zero org.disable_saml events identified.”
SAML is enabled and the IdP is connected. But “Require SAML SSO authentication for all members” was never checked — it requires a deliberate separate action after enabling. All members can still authenticate using their GitHub username and password. Every provisioning and deprovisioning control in this framework is undermined by this single unchecked checkbox. This is the most common SSO control gap.
SSO enforcement is active and correctly configured. But 15 service accounts and 3 senior engineers have been added to the SSO exemption list over two years. Two of the exempt engineers have since left the company. Their accounts remain active and exempt because the exemption list is never reviewed — it’s not part of the quarterly access certification process and no one knows it exists.
Auditors test whether SSO enforcement is enabled. They rarely pull the SSO exemption list. Ask specifically: “Provide the complete list of accounts currently exempted from SAML enforcement, with the business justification and approval date for each.”
Why These Frameworks Exist.
Traditional governance frameworks established foundational control principles for enterprise technology environments. Modern platforms introduced a different challenge: cloud-native architectures, CI/CD pipelines, automation layers, APIs, distributed identity models, and continuously evolving configuration surfaces. The challenge is no longer understanding whether controls should exist. The challenge is understanding how governance should be designed for platforms that operate fundamentally differently than traditional infrastructure environments.
Each framework is purpose-built for a specific platform ecosystem — not adapted from a generic control template. GitHub governance differs from AWS. Okta differs from Azure DevOps. The controls are designed around how the platform actually operates, how trust is established, and where modern governance dependencies emerge.
Traditional guidance often defines control objectives at a high level while leaving implementation interpretation to individual teams. The Aethos frameworks provide architectural direction for how governance should operate within modern platform environments, reducing ambiguity that frequently leads to inconsistent or inherited control design.
The frameworks are shaped through direct experience designing, implementing, evaluating, and governing modern cloud and platform ecosystems. They reflect operational realities encountered inside evolving enterprise environments — not theoretical mappings created independently from platform behavior.
Not templates. Not compliance mappings.
Most compliance documentation tells you a control should exist. Aethos Frameworks tell you how to design it, where it breaks, what evidence it produces, and what auditors actually look for when they test it.
- Control objectives with framework citations but no implementation detail
- Generic descriptions like “ensure access is reviewed periodically”
- Guidance written without reference to any specific platform
- Blank evidence tables for you to fill in yourself
- One approach regardless of your environment or maturity
- No guidance on what auditors actually test or where they find gaps
- Platform-specific controls mapped to runtime behavior, not documentation assumptions
- Four maturity levels per control from manual baseline to fully automated
- Step-by-step implementation with real CLI queries and API commands
- Evidence tables with the specific format and content auditors will request
- Failure mode analysis showing exactly how and why each control breaks
- DoE and ToE procedures written for PCAOB AS 2201
- Drift signals for continuous monitoring between audit cycles
Designed for the Reality of Modern Platforms
Across organizations at different stages of platform maturity, leaders consistently describe the same realization: traditional control models were never designed for interconnected, automated ecosystems. The Aethos frameworks help expose governance gaps many teams did not recognize until modern platform risks were mapped beyond legacy audit assumptions.
“Many assurance programs are still applying traditional ITGC thinking to highly interconnected platform ecosystems — without realizing the architecture itself has fundamentally changed.”
“Technology environments matured faster than many governance models evolved. As a result, teams often inherit controls designed for static infrastructure into platforms operating through automation, integrations, and continuous deployment.”
“Organizations frequently believe their SOX environments are mature because controls exist and testing passes — while critical ecosystem dependencies remain outside the scope of traditional assurance.”
“One of the biggest gaps in modern assurance is not control execution — it’s understanding how today’s platforms actually operate beneath the control framework.”
“Many audit leaders were never expected to think architecturally about cloud-native ecosystems. The challenge is that modern platforms now require governance visibility beyond legacy ITGC structures.”
22 frameworks.
Browse by platform stack.
Control number and name are visible to everyone. Full access — all 7 tabs per control — requires an annual subscription at $799/year. Use Rationale to scope your audit, Design to brief engineering, Implementation to close gaps, and Drift & Detection to monitor between cycles.
Don’t see your platform?
The framework library is expanding continuously. If you’re dealing with a platform environment without a framework yet, reach out — we may already be building it.
Platforms under consideration include Docker, Datadog, Spinnaker, GitHub Actions, Prometheus, Grafana, and others. Priority is influenced by subscriber requests.
[email protected]New frameworks release first
through the Aethospect.
Subscribe for early access to frameworks in development, notifications when specific technologies release, and input into which platforms are prioritised next.
Join the AethospectFree. No spam. Unsubscribe anytime.