Evidence automation¶
Most compliance evidence is a question about a system, not a question about a person: who has access, is MFA enforced, was that account disabled when the employee left, did that code change get approved. The platform answers those questions by reading your environment directly, so your team is left only with the evidence that genuinely requires a human.
This page is the honest inventory: what one scan collects on its own, what still needs a person, and what you have to grant us once to make the first list possible.
Read-only, always
Every connector below is read-only. The platform never writes to your tenant, your repositories, or your directory, and secrets stay in your Key Vault. See Compliance scan permissions.
What you grant once¶
| Connector | What it unlocks | What you grant |
|---|---|---|
| Azure + Microsoft 365 | Identity, access, device, logging, encryption and governance evidence | Reader on the subscription, plus an admin-consented read-only Graph app |
| GitHub | Change-management evidence (approvals, branch protection, 2FA) | A fine-grained read-only token for the organization |
Both are one-time grants. After that, every scheduled scan refreshes the evidence without another request to your team.
Azure + Microsoft 365¶
A single Azure + M365 scan evaluates 110 catalogued controls and collects evidence automatically for 79 of them. The identity and access evidence is what SOC 2, CMMC and FedRAMP assessors ask for first:
| Evidence | What is collected |
|---|---|
| User roster | Every directory identity, enabled vs. disabled, member vs. guest, with job title, hire date and account creation date |
| Privileged access | Global Administrator roster and directory role membership, for least-privilege testing |
| Password / authentication policy | Enabled authentication methods and the domain password validity period |
| MFA and conditional access | Conditional access policies, named locations, Security Defaults state, sign-in frequency and session controls |
| Offboarding | Disabled accounts plus the Disable account audit events showing when each was cut off |
| Access changes | Role-management and group-management audit events for the period |
| Stale accounts | Last interactive sign-in per enabled account |
| Licensing | Tenant license roster |
| Devices | Intune compliance and configuration policies: encryption, session lock, removable media, malware protection |
| Logging | Diagnostic settings, log workspaces and the audit export pipeline |
| Data protection | Storage and Key Vault encryption posture, backup and recovery configuration, sensitivity labels |
| Security posture | Defender for Cloud secure score, assessments, security contacts and policy assignments |
Controls the credential cannot reach are reported as partial with an explanation. They are never reported as passing.
Auditor-ready per-user tables¶
By default the evidence is summarised at the tenant level ("42 enabled accounts"). Auditors usually want the underlying list. Enable the per-user evidence export and the same scan additionally emits the row-level tables an assessor samples from:
That produces the full user roster with hire and creation dates, the disabled account list, the leaver disable events with timestamps and who performed them, the Global Administrator roster, and the role and group change history.
Audit-log retention shapes what you can prove
Entra ID retains directory audit events for a limited window, commonly 30 days. Events older than that window are gone regardless of who asks. For a Type 2 audit covering 6 to 12 months, the scan must run on a schedule through the period so each run captures its own window. A single scan at the end of the period cannot reconstruct the beginning of it.
GitHub¶
The github_compliance scan collects the change-management evidence behind
SOC 2 CC8.1 and NIST 800-171 3.4.3 / 3.4.4:
- Branch protection per repository: required reviews, approval counts, CODEOWNERS, admin enforcement and force-push posture
- Merged pull request export for a date range, with pre-merge approval metadata: who authored, who approved, and when. Approvals submitted after the merge are excluded, because they do not evidence the control
- Organization roster with two-factor enforcement state
Set the audit period on the scan so the export matches what your auditor is testing:
Availability
The GitHub connector is in final review and ships in the next scanner release. Until then, change-management evidence is collected manually. Ask your Scan Ninja contact for current status.
SOC 2 coverage at a glance¶
| TSC category | Status |
|---|---|
| CC6.x Logical and physical access | Automated (identity, MFA, conditional access, offboarding, encryption in transit) |
| CC7.x System operations | Automated (asset inventory, vulnerability detection, monitoring deltas, incident indicators) |
| CC8.x Change management | Automated for approvals and branch protection via the GitHub connector; SDLC policy documents remain manual |
| A1.x Availability | Automated (reachability history, backup and redundancy configuration) |
| PI1.x Processing integrity | Partially automated |
| CC1.x Control environment | Manual |
| CC2.x Communication and information | Manual |
| CC3.x Risk assessment | Manual |
| CC4.x Monitoring activities | Manual |
| CC5.x Control activities | Manual |
| CC9.x Risk mitigation | Manual |
What still needs a person¶
Automation stops where the evidence is a human judgement or a paper record. For these, expect to supply the artifact:
| Evidence | Why it stays manual |
|---|---|
| Governance and ethics, board oversight | Organizational facts with no technical artifact |
| Risk register, risk treatment | A judgement your team makes and signs |
| Vendor reviews, business continuity plans | Contractual and policy documents |
| Security awareness training records | Lives in your training provider, not your cloud |
| Background screening | Lives with your screening provider |
| Access approvals for new hires and role changes | We can show you what changed and when; the approval trail is yours. The scan output tells you exactly which events need one, so nobody is guessing |
| Access review sign-off | The review has to actually happen. We generate the user and permission listing so the review is a sign-off, not a project |
| Media disposal and sanitisation | Physical process |
| Physical and environmental controls | Facility process |
| Incident response plan and tabletop exercises | Documented exercise, run by your team |
Evidence, not attestation
The platform produces evidence. It does not issue attestations. Use these artifacts to support your auditor's testing; your auditor decides what each one proves.
Type 1 and Type 2¶
Type 1 and Type 2 test the same controls. The difference is time: Type 1 asks whether controls are designed and implemented at a point in time, Type 2 asks whether they operated throughout a period.
For Type 1, one scan per connector is enough. For Type 2, put the compliance scans on a recurring schedule (weekly at minimum) covering the whole assessment period. Each run is a timestamped artifact, and the set of them is the operating effectiveness evidence. Combined with the retention limits above, scheduling is not an optimisation for Type 2, it is the requirement.