The full mapping, by check name and TSC 2017 criterion.
Which AICPA Trust Services Criterion does each automated check map to?
Every automated check is tagged in code with the AICPA TSC 2017 criterion and the PCI DSS 4.0.1 requirement it provides evidence for. The 54 checks span eleven unique SOC 2 criteria, concentrated in Security (CC6), System Operations (CC7), and Change Management (CC8), with availability (A1) covered by S3 versioning, and each is also mapped to a PCI DSS 4.0.1 requirement.AWS (19)MFA enabled for all IAM users (CC6.1). Root account has no active access keys (CC6.1). No credentials unused for 90+ days (CC6.2). Strong password policy configured (CC6.1). S3 public access block enabled (CC6.1). S3 buckets encrypted at rest (CC6.1). S3 versioning enabled on critical buckets (A1.2). CloudTrail enabled in all regions (CC7.2). CloudTrail log file validation enabled (CC7.2). GuardDuty enabled in all regions (CC7.2). RDS instances encrypted at rest (CC6.1). EBS default encryption enabled (CC6.1). VPC Flow Logs enabled (CC7.2). CloudWatch alarm for root account usage (CC7.2). CloudWatch log groups retain at least 12 months (CC7.2). RDS instances use a non-default master username (CC6.1). No security groups expose SSH/RDP/DB ports to the internet (CC6.1). Load balancer HTTPS listeners require TLS 1.2+ (CC6.1). RDS instances enforce TLS at the parameter group (CC6.1).GitHub (5)2FA required for all org members (CC6.1). Default branch protection enabled (CC8.1). Required status checks on default branch (CC8.1). Secret scanning enabled (CC6.1). Dependabot security alerts enabled (CC7.1).GCP (15)2-Step Verification enforced for all Google Workspace users (CC6.1). Cloud Audit Logs enabled for all services (CC7.2). GCS buckets block public access (CC6.1). Uniform bucket-level access enabled (CC6.1). VPC Flow Logs enabled on all subnets (CC7.2). Service account keys not older than 90 days (CC6.2). Primitive IAM roles (Owner/Editor) not assigned to users (CC6.1).Azure (15)MFA enforced via Security Defaults or Conditional Access (CC6.1). Storage account public blob access disabled (CC6.1). Activity Log diagnostic settings configured (CC7.2). Microsoft Defender for Cloud enabled on key workloads (CC7.2). Azure Key Vault in use for secrets management (CC6.1). Managed disks encrypted at rest (CC6.1). No stale Azure AD guest users (CC6.2).The 49 manual controls are mapped the same way, with criteria from CC1 (control environment), CC3 (risk), CC5 (control activities), CC7.4/CC7.5 (incident response), CC9 (business continuity, vendor), and A1.2 (DR testing). Most also carry a PCI DSS 4.0.1 requirement, and 8 are PCI-specific controls for SAQ A / A-EP merchants. The full list of automated and manual criteria is exported in every report the auditor portal generates.
What AWS permissions do the checks need?
The AWS SecurityAudit managed policy covers all 19 AWS checks. It is read-only, no resources are created, modified, or deleted. Attach it to an IAM user or role dedicated to Scorifya. Your AWS credentials are stored in your own database and never leave your infrastructure.
A check failed but we have a compensating control. Can we mark it as acceptable?
Today, checks report pass or fail based on what they observe in your cloud account. There is no in-app way to mark a failing check as 'accepted risk.' If you have a compensating control, document it in the corresponding manual control's notes field, upload the supporting evidence, and include an explanation in the audit notes you give your CPA. Most auditors accept well-documented compensating controls.
Risk acceptance / exception flagging is on the roadmap.
How often do the checks run?
On demand from the dashboard, or on a schedule via a cron job. You configure the schedule by calling POST /api/cron/run from any cron service (system cron, GitHub Actions, an external scheduler). If you set CRON_SECRET, that request must include x-cron-secret: <value> in the header. Most teams run checks daily or twice daily.
Can checks fail due to our cloud provider's eventual consistency, not a real problem?
Rarely for the checks Controls runs, because they query resource configuration rather than real-time state. However, newly created resources (a new IAM user, a new S3 bucket) may not show the expected configuration for a few minutes. Re-running the checks after a few minutes will reflect the settled state.
We use AWS Organizations and have multiple accounts. How does that work?
Controls connects to one set of AWS credentials per instance. If you run workloads across multiple AWS accounts, you can connect the account where your most sensitive workloads live, or set up a cross-account IAM role that grants the SecurityAudit policy across your organization. The checks run against whichever account the credentials belong to.
We don't use AWS. Can we still use Controls for GitHub, GCP, and Azure only?
Yes. Each cloud provider is connected independently. You can connect any combination, GitHub only, GCP only, Azure + GitHub, and the checks run only for the providers you've configured. The 38-check total reflects all four providers; your posture score reflects only the checks you've enabled.