Okta, GitHub, and AWS are three of the most common SOC 2 control evidence sources for mid-market SaaS companies. They're also three of the most common places where evidence gaps live — not because these platforms lack APIs or audit logs, but because the specific data fields that compliance programs need and the default export formats these platforms provide don't always align cleanly.
This piece covers the specific evidence gaps that appear most frequently in compliance programs using these three systems, the root cause in each case, and what complete evidence actually looks like when the data is pulled correctly.
Okta evidence gaps
Okta is the primary evidence source for CC6.1 (logical access to authorized users) and CC6.3 (access removal upon termination) in most programs that use it as their identity provider. The gaps that appear most frequently are not about the availability of the data — Okta has comprehensive audit logs and a detailed API — but about what fields are included in standard compliance evidence pulls.
The suspended vs. deactivated distinction. Okta has two distinct non-active user states: Suspended and Deactivated. A Suspended user cannot authenticate but their account still exists and retains group membership records. A Deactivated user is fully removed from the directory. For SOC 2 evidence purposes, the control test for CC6.3 is whether access was removed upon termination — and depending on your offboarding process, terminated users may be Suspended rather than Deactivated for some period. A user access list export that shows all non-Deactivated users as "active" can make your offboarding look cleaner than it is. Evidence that includes user status with status timestamp provides the full picture.
Application assignment source. Okta can assign application access to users either through group membership or through direct assignment. A compliance evidence pull that only shows direct assignments misses users who have application access through group inheritance. The complete picture of who has access to a given application requires listing both direct assignments and all group memberships that grant access to the application — a multi-query operation, not a single export.
MFA enrollment coverage. CC6.6 and ISO 27001 control 8.5 both require strong authentication. For an Okta-based MFA program, the evidence is the MFA enrollment and enforcement configuration. But teams frequently produce only the enforcement policy (showing MFA is required) without the enrollment coverage evidence (showing what percentage of users are actually enrolled and whether any users have active exceptions). A policy that requires MFA and an enrollment record showing 94% compliance are two different things — the auditor needs both.
Authentication log retention. Okta's system log retains authentication events, but the default retention period on many Okta plans is 90 days. For a 12-month SOC 2 observation period, the system log from the start of the period may no longer be accessible at audit time if logs aren't being forwarded to external storage. Teams that don't forward Okta logs to a SIEM or log retention service face a gap in authentication evidence for the first portion of their observation period.
GitHub evidence gaps
GitHub is the primary evidence source for CC8.1 (change management via protected branches and pull request approval workflows) and a secondary source for CC6.1 (access control over source code). The gaps here tend to be more about the structure of organizations and repositories than about API limitations.
Multi-organization sprawl. Many growing SaaS companies have more than one GitHub organization — a primary engineering organization and secondary organizations for open-source projects, acquired companies, or legacy projects. SOC 2 scope for change management typically covers the repositories where production code lives. If production code exists across multiple GitHub organizations, evidence needs to cover all of them. Teams frequently produce complete evidence for the primary organization and miss repositories in secondary organizations entirely.
Branch protection granularity. The existence of branch protection on a repository's main or production branch is one evidence artifact. Whether that branch protection requires the specific controls your policy mandates — minimum required reviewers, dismissal of stale reviews on new commits, required status checks — is a different, more granular question. Evidence for CC8.1 should include the branch protection configuration for each in-scope repository, not just whether branch protection is enabled. The specific rules within the branch protection policy determine whether the change management control is actually operating as designed.
External collaborator access. GitHub organizations typically have a mix of full members (typically employees) and outside collaborators (contractors, partners, integration bots). Access review evidence for GitHub needs to cover both populations separately. Outside collaborators don't appear in the organization member list and can have direct repository access without going through the organization membership workflow. Teams often review org membership but miss outside collaborator access entirely — a gap that can surface as a finding when an auditor checks the org membership against the full collaborator list.
Actions and secrets. GitHub Actions workflows can access repository secrets and organization-level secrets for CI/CD automation. The secrets themselves are encrypted and not readable via API, but the list of secrets, their scope (repository vs. organization), and the Actions workflows that reference them are all observable. For SOC 2 programs that include CI/CD pipeline controls, the secrets configuration and Actions workflow review are evidence artifacts that many teams haven't explicitly included in their control scope.
AWS evidence gaps
AWS is the highest-complexity evidence source for most SaaS companies and the area where evidence gaps are most consequential. The primary challenge is the combination of multi-account environments, IAM complexity, and the sheer volume of potentially relevant configuration data.
Cross-account coverage. Many growing SaaS companies operate multiple AWS accounts — separate accounts for production, staging, development, and sometimes separate accounts per product line or geographic region. SOC 2 evidence for CC6.1, CC6.2, and CC6.3 needs to cover all accounts where data subject to the system description is processed. Evidence that covers only the primary production account misses stale access in secondary accounts — which, as described in the access control drift article, is one of the most common gaps auditors find.
IAM policy effectiveness vs. assignment. IAM evidence for access control typically includes IAM user lists, role lists, and group memberships. But the evidence that matters for CC6.1 is the effective permissions a given principal has — which depends not just on what roles are assigned, but on the policies attached to those roles, whether those policies are customer-managed or AWS-managed, and whether resource-based policies (S3 bucket policies, KMS key policies, resource-based policies on other services) grant additional access independent of IAM role assignment. Producing a user-to-role mapping is necessary but not sufficient; the policy analysis needs to go one level deeper to show what actions each role actually permits.
CloudTrail coverage gaps. CloudTrail is the primary audit trail for API actions in AWS. For CC7.2 (environmental threat monitoring), evidence that CloudTrail was enabled throughout the observation period is required. But CloudTrail configuration has several variables that affect coverage completeness: whether it's enabled in all regions or only in the primary region, whether it logs management events only or also data events for S3 and Lambda, and whether log file validation is enabled (confirming that logs haven't been tampered with). Teams frequently produce evidence showing CloudTrail is enabled without demonstrating that it's configured to cover the full scope of API activity.
Security group configuration drift. Security groups are the primary network access control mechanism in AWS VPCs. CC6.6 and CC6.7 (physical and logical access from external parties restricted) have direct mapping to security group rules that limit inbound access to production systems. Security group configurations can change frequently — during incident response, during infrastructure updates, and during development work that spills into production accounts. Evidence at a point in time shows the current configuration; evidence over a period requires either configuration change logs (CloudTrail API call records for ec2:AuthorizeSecurityGroupIngress and related calls) or continuous configuration monitoring.
The cross-system reconciliation problem
Many of the gaps described here share a root cause: they require cross-referencing data from multiple systems to answer a compliance question that any single system can't answer alone. Who has admin access to the production AWS account AND has no active employment record? Which GitHub organization members are NOT in the Okta user directory? These questions require joining data across systems — and that joining step is where manual evidence collection consistently fails to produce complete evidence.
The solution isn't better manual processes. It's a monitoring architecture that connects to all relevant systems simultaneously and can execute cross-system queries automatically. When an access review isn't a multi-day manual process but a continuously updated cross-reference, the evidence gaps described here become detectable in hours rather than discoverable in pre-audit scrambles.