Compliance scan permissions¶
Scan Ninja's Compliance Validations scans authenticate to your cloud and read its configuration to produce compliance evidence. This page lists exactly what access to grant for Microsoft Azure / M365, Amazon Web Services, and Google Cloud.
One scan, three frameworks — read-only
A compliance scan reads your cloud's control plane once and records each control's result as CMMC / NIST 800-171 evidence. Scan Ninja then maps every result to FedRAMP and TX-RAMP (NIST 800-53 Rev 5) automatically. You do not grant different access per framework — the permissions are per cloud, and they are always read-only. CMMC, FedRAMP Low/Moderate/High, and TX-RAMP Level 1/2/3 all read the same resources; the framework and level only change which baseline your results are scored against.
HIPAA is a separate scan
HIPAA reads the same Azure surfaces with the same read-only access, but it is its own scan type rather than a mapping of the CMMC results, because it needs two things the others don't: your entity type (covered entity or business associate) and the scope of ePHI. See HIPAA Security Rule scans.
Least privilege, no secrets stored
The scanner never needs write, delete, or administrative permissions on any cloud. Scan Ninja never stores your cloud secret — you either grant a role the scanner assumes, or you place the secret in your own Azure Key Vault and give Scan Ninja a pointer (the vault URL + secret name). The secret is resolved at scan time and never written to our database or logs.
You choose the cloud in the Create Scan wizard (Compliance Validations → pick a framework → Target Cloud), then fill in the fields below.
Microsoft Azure / M365¶
Azure has two independent surfaces. Azure Resource Manager (ARM) is always read. Microsoft 365 / Graph is read only when you enable the "Also run Microsoft 365 (Graph) checks" toggle (the full Azure + M365 sweep).
ARM — subscription resources¶
Assign the built-in Reader role, scoped to the subscription(s) you want
assessed (not the whole tenant unless you intend to scan everything). Reader is
read-only and covers everything the scan inspects:
- Storage accounts, disks, and Key Vaults
- Virtual networks and network security groups
- Virtual machines and compute configuration
- Microsoft Defender for Cloud assessments and secure score
- Azure Policy compliance state
- Recovery Services (backup / disaster recovery)
- Diagnostic settings (the audit-logging pipeline)
Tighter than Reader
If your policy disallows the broad Reader role, use a custom role that
grants only the */read actions on the resource types above. Never assign
Contributor or Owner.
Microsoft 365 / Graph — only with the M365 toggle¶
Register an app with admin-consented, read-only application Graph permissions:
| Permission | Used for |
|---|---|
Directory.Read.All |
users, groups, roles, conditional access |
Policy.Read.All |
authentication / MFA / conditional-access policies |
DeviceManagementConfiguration.Read.All |
Intune compliance policies |
DeviceManagementManagedDevices.Read.All |
device compliance |
AuditLog.Read.All |
sign-in and audit logs |
InformationProtectionPolicy.Read.All |
sensitivity labels / DLP |
SecurityIncident.Read.All |
Defender / Sentinel incidents — HIPAA scans only |
Admin consent requires a Global Administrator or Privileged Role Administrator. Ask your Scan Ninja contact for the automated setup script that creates this app with exactly these read-only scopes.
Intune checks need this app, not the Azure CLI
DeviceManagementConfiguration.Read.All and
DeviceManagementManagedDevices.Read.All must be granted on this app
registration. The Azure CLI's own first-party application does not hold
DeviceManagement scopes, so device and workstation controls cannot be read
through a plain az-based credential. Without this app, those controls report
partial, not fail.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Target Cloud | Microsoft Azure / M365 |
| Azure Subscription ID | the subscription to assess |
| Azure Environment | Commercial, or Government for FedRAMP High / DoD IL4+ (sovereign endpoints) |
| Tenant ID / Client (App) ID | your service-principal / app-registration IDs (optional if using Managed Identity) |
| Key Vault URI + Secret Name | pointer to the app secret in your Key Vault (never paste the secret) |
| Microsoft 365 toggle | on = full Azure + M365 sweep; off = ARM only |
Running with ARM-only credentials is fine — the M365 controls simply report partial instead of failing.
HIPAA Security Rule scans¶
HIPAA scans read the same Azure and M365 surfaces as every other framework —
Reader on the subscription plus the Graph app above. Two things differ.
One extra Graph permission. SecurityIncident.Read.All lets the scan read
security incidents when confirming that a breach-response workflow exists
(§ 164.308(a)(6)(ii)). Everything else HIPAA needs, including the
sensitivity-label check for identifying ePHI, is already covered by the
permissions above.
Sentinel analytics and automation rules need no extra permission
The other half of the § 164.308(a)(6)(ii) check — do enabled analytics rules
and an automation rule / playbook actually exist — reads
Microsoft.SecurityInsights resources through Azure Resource Manager,
not Microsoft Graph. Those are already covered by the subscription-scoped
Reader role above. Only the incident read goes through Graph.
You must tell us where ePHI lives. This is the one framework where scoping is not optional:
| Wizard field | What to provide |
|---|---|
| Entity Type | Covered Entity or Business Associate — selects which organizational requirements (§ 164.314) apply |
| ePHI Resource Groups | the resource groups holding electronic protected health information, e.g. rg-ehr-prod |
| ePHI Tag Filter | (alternative) a tag identifying ePHI resources, e.g. dataClassification=ePHI |
An unscoped HIPAA scan is worse than no scan
Without an ePHI scope, every check runs against every resource in the subscription. Marketing websites and build agents get assessed as though they held patient data, and the resulting gap list buries the findings that matter. Scope to the resource groups or tags that actually handle ePHI.
Roughly a third of the Security Rule cannot be scanned by anyone. Of the 51 assessable items in 45 CFR Part 164 Subpart C, 20 are facility, workforce, and policy requirements with no cloud signal — sanction policy, workforce clearance, facility security plan, maintenance records, training delivery. These are flagged needs attestation and you upload the evidence. No credential changes that.
Addressable is not optional
22 of the 51 items are Addressable, which does not mean optional. You must implement the specification, document an equivalent alternative, or document why it is not reasonable and appropriate and accept the residual risk. When an automated check fails on an Addressable item, Scan Ninja records an addressable gap and prompts you to choose — it does not report a violation.
Business Associate Agreements are never auto-verified
Scan Ninja does not assert that your Microsoft BAA is signed. Azure BAA coverage is extended through the Microsoft Product Terms and Data Protection Addendum for eligible agreements, and it is not readable from any API. The scan reports the eligibility signals it can observe and asks you to confirm the agreement — BAA status (§ 164.314(a)(2)(i)) always carries an attestation.
Amazon Web Services¶
Grant a single read-only IAM role and let the scanner assume it. The simplest
option is AWS's managed SecurityAudit policy (read-only across services). If
you prefer a tighter custom policy, grant only these actions:
| Area | Read-only actions |
|---|---|
| S3 (public access, encryption, TLS) | s3:ListAllMyBuckets, s3:GetBucketPublicAccessBlock, s3:GetEncryptionConfiguration, s3:GetBucketPolicy |
| IAM (MFA, password policy, root keys) | iam:GetAccountSummary, iam:GetAccountPasswordPolicy |
| CloudTrail (audit logging) | cloudtrail:DescribeTrails |
| KMS (key management + rotation) | kms:ListKeys, kms:GetKeyRotationStatus |
| EC2 security groups (network boundary) | ec2:DescribeSecurityGroups |
| GuardDuty (threat monitoring) | guardduty:ListDetectors |
| AWS Config (baseline / inventory) | config:DescribeConfigurationRecorders, config:DescribeConfigurationRecorderStatus |
Recommended: cross-account AssumeRole¶
Create a read-only role in the target account that trusts Scan Ninja's scanner, protected by an External ID (this prevents the "confused deputy" problem). No long-lived key ever leaves your account.
Trust policy (attach the SecurityAudit managed policy, or your tighter custom
policy, to this role):
{
"Effect": "Allow",
"Principal": { "AWS": "<scan-ninja-scanner-principal-arn>" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "<your-external-id>" } }
}
Scan Ninja provides the scanner principal ARN to put in
Principal. Choose your own External ID and enter the same value in the wizard.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Target Cloud | Amazon Web Services |
| AWS Account ID | the 12-digit account to assess |
| Region | e.g. us-east-1; use a us-gov-* region for GovCloud (FedRAMP High) |
| AssumeRole ARN | the ARN of the read-only role above (recommended) |
| External ID | your chosen confused-deputy guard value |
| Key Vault URI + Secret Name | (alternative to a role) pointer to read-only access keys stored in your Key Vault |
Google Cloud¶
Grant read-only IAM on the project you want assessed. One combination covers everything the scan reads:
roles/iam.securityReviewer— read the IAM policy and audit configsroles/viewer— read resource configuration
Prefer granular viewer roles if roles/viewer is broader than your policy allows:
| Area | Granular read-only role |
|---|---|
| Cloud Storage (public access, CMEK, uniform access) | roles/storage.bucketViewer |
| Cloud Logging (sinks / retention) | roles/logging.viewer |
| Cloud KMS (key rings) | roles/cloudkms.viewer |
| VPC firewalls (default-deny, open ports) | roles/compute.viewer |
Never grant editor or owner
roles/iam.securityReviewer + roles/viewer is entirely read-only. Do not
grant roles/editor or roles/owner.
Authenticate with Workload Identity Federation (no key material — preferred) or a service-account JSON placed in your Key Vault and referenced by pointer.
How to enter it¶
| Wizard field | What to provide |
|---|---|
| Target Cloud | Google Cloud |
| GCP Project ID | the project to assess |
| Key Vault URI + Secret Name | (optional) pointer to a service-account JSON in your Key Vault; omit when using Workload Identity Federation |
What one scan produces¶
- The scan verifies each automatable control and records it as CMMC / NIST
800-171 evidence (e.g. control
3.13.16, "protect CUI at rest"). - Each result is mapped to the equivalent NIST 800-53 Rev 5 controls (e.g.
SC-28) and stored under both FedRAMP and TX-RAMP labels. - Your FedRAMP impact (Low / Moderate / High) or TX-RAMP level (1 / 2 / 3) selects which 800-53 baseline the same results are scored against.
A HIPAA scan instead records each result against the implementation specifications of 45 CFR Part 164 Subpart C, scoped to the ePHI resource groups you nominate, and reports a weighted risk score (0–100%) rather than an SPRS score — the Security Rule has no numeric score to submit anywhere.
Coverage is an honest, automatable subset per cloud — Azure is the deepest, while AWS and GCP cover the controls that map cleanly to their APIs. Controls that can't be verified by API (physical, personnel, and policy controls) are handled as attestations, never marked automatically satisfied.
Evidence, not an attestation
Compliance scans produce evidence to support your assessment — they are not a FedRAMP/TX-RAMP authorization or a substitute for an assessor. See the Compliance overview for how Scan Ninja evidence fits your audit.