Integrations

AWS Integration User Guide

Overview AuditBadger's AWS integration automatically collects compliance evidence from your Amazon Web Services infrastructure. Once connected, it runs checks on configured schedules and gathers evidence that supports assessments for SOC 2 and ISO 27001 compliance frameworks. Key Benefits - Automated evidence collection - No more manual screenshots or exports - Compliance-focused collection - Evidence collected on schedule (weekly or monthly) - Auto-verification - Many evidence sources are automatically checked against compliance rules - Multi-framework support - A single integration provides evidence that can support controls across SOC 2 and ISO 27001 Security Model - Read-only access - AuditBadger cannot modify your AWS resources - Cross-account role assumption - Secure AWS STS-based authentication - External ID protection - Prevents confused deputy attacks - Auditable sessions - AWS API activity is attributable to the assumed AuditBadger role session in CloudTrail where AWS records the relevant management events Existing roles created under the previous HumadroidComplianceRole name can remain connected. New setup instructions use AuditBadgerComplianceRole by default. Evidence Sources The AWS integration collects 20 distinct evidence types across six categories: Identity & Access Management IAM Password Policy - Description: Verifies password complexity, length, expiration, and reuse requirements - Frequency: Monthly - Auto-Verify: Yes IAM MFA Status - Description: Verifies multi-factor authentication is enabled for all users including root - Frequency: Monthly - Auto-Verify: Yes IAM Access Keys - Description: Monitors access key rotation, usage patterns, and lifecycle - Frequency: Monthly - Auto-Verify: Yes Logging & Monitoring CloudTrail Configuration - Description: Verifies audit logging is enabled and properly configured - Frequency: Monthly - Auto-Verify: Yes CloudTrail Events - Description: Audit trail of API calls and management events - Frequency: Monthly - Auto-Verify: No CloudWatch Alarms - Description: System monitoring and alerting configuration - Frequency: Monthly - Auto-Verify: Yes VPC Flow Logs - Description: Network traffic logging configuration - Frequency: Monthly - Auto-Verify: Yes Security Services GuardDuty Status - Description: Threat detection service status and configuration - Frequency: Monthly - Auto-Verify: Yes GuardDuty Findings - Description: Security threats and anomalies detected - Frequency: Weekly - Auto-Verify: No Security Hub Status - Description: Consolidated security findings service status - Frequency: Monthly - Auto-Verify: Yes AWS Config Status - Description: Configuration change tracking service status - Frequency: Monthly - Auto-Verify: Yes Network Security Security Groups - Description: Network security rules and firewall configuration - Frequency: Monthly - Auto-Verify: Yes Network ACLs - Description: Network access control list rules - Frequency: Monthly - Auto-Verify: Yes Encryption & Data Protection S3 Bucket Encryption - Description: Verifies all S3 buckets have encryption enabled - Frequency: Monthly - Auto-Verify: Yes S3 Public Access Block - Description: Verifies S3 buckets block public access - Frequency: Monthly - Auto-Verify: Yes RDS Encryption - Description: Checks RDS storage encryption, public accessibility, and Multi-AZ configuration - Frequency: Monthly - Auto-Verify: Yes EBS Volume Encryption - Description: Verifies EBS volumes are encrypted - Frequency: Monthly - Auto-Verify: Yes KMS Key Rotation - Description: Verifies KMS keys are configured for automatic rotation - Frequency: Monthly - Auto-Verify: Yes Backup & Recovery AWS Backup Jobs - Description: Backup execution and success monitoring - Frequency: Weekly - Auto-Verify: Yes RDS Snapshots - Description: Checks automated and manual snapshot coverage, retention settings, and snapshot encryption - Frequency: Monthly - Auto-Verify: Yes Compliance Coverage and Verification For the detailed SOC 2 and ISO 27001 mappings, default verification rules, and evidence-to-control matrix, see the AWS Integration Control Coverage Guide. Getting Started To set up the AWS integration: 1. Navigate to Settings > Integrations > AWS 2. Click Connect AWS Account 3. Follow the setup wizard to create an IAM role in your AWS account 4. Paste the Role ARN and validate the connection 5. Enable evidence sources for your compliance controls For detailed setup instructions, see the AWS Setup Guide. AWS Permissions Required The AuditBadger CloudFormation template creates a cross-account role with: - the AWS-managed SecurityAudit policy - an AuditBadger inline policy for the integration's evidence checks - a trust policy restricted by the customer-specific external ID AWS maintains SecurityAudit and can change its permissions independently. Its effective permissions are broader than the API operations AuditBadger's current evidence collectors call. API Operations Used by AuditBadger The current integration and shipped AWS evidence collectors use these operations: Connection and region discovery sts:GetCallerIdentity iam:ListAccountAliases ec2:DescribeRegions IAM iam:GetAccountPasswordPolicy iam:ListUsers iam:ListMFADevices iam:GetLoginProfile iam:ListAccessKeys iam:GetAccessKeyLastUsed iam:GetAccountSummary CloudTrail, CloudWatch, and AWS Config cloudtrail:DescribeTrails cloudtrail:GetTrailStatus cloudtrail:LookupEvents cloudwatch:DescribeAlarms config:DescribeConfigurationRecorders config:DescribeConfigurationRecorderStatus config:DescribeDeliveryChannels config:DescribeConfigRules config:GetComplianceSummaryByConfigRule GuardDuty and Security Hub guardduty:ListDetectors guardduty:GetDetector guardduty:ListFindings guardduty:GetFindings securityhub:DescribeHub securityhub:GetEnabledStandards securityhub:GetFindings EC2 networking and EBS ec2:DescribeVpcs ec2:DescribeFlowLogs ec2:DescribeSecurityGroups ec2:DescribeNetworkAcls ec2:DescribeVolumes ec2:GetEbsEncryptionByDefault S3 s3:ListAllMyBuckets s3:GetBucketLocation s3:GetBucketEncryption s3:GetAccountPublicAccessBlock s3:GetBucketPublicAccessBlock RDS rds:DescribeDBInstances rds:DescribeDBSnapshots KMS and AWS Backup kms:ListKeys kms:DescribeKey kms:GetKeyRotationStatus backup:ListBackupPlans backup:ListBackupVaults backup:ListBackupJobs The CloudFormation role grants a superset of this list. Do not assume that the inline policy alone is a complete replacement for SecurityAudit; validate all operations above when creating a narrower custom role. RDS Database Log Contents The AWS-managed SecurityAudit policy currently includes: rds:DownloadDBLogFilePortion AWS documents this action as permission to download all or part of an RDS database log file. AuditBadger does not call this operation, and no current evidence check retrieves or stores RDS database log contents. The two RDS evidence checks use only: - RDS Encryption - rds:DescribeDBInstances - RDS Snapshots - rds:DescribeDBInstances and rds:DescribeDBSnapshots Customers can explicitly deny rds:DownloadDBLogFilePortion on the AuditBadger role without affecting current evidence collection. Under AWS IAM policy evaluation, an explicit deny overrides an allow inherited from SecurityAudit. For the operation definition, see the AWS DownloadDBLogFilePortion API reference. For deny behavior, see AWS IAM policy evaluation logic.

GitHub Integration User Guide

Humadroid Compliance Platform Overview Humadroid's GitHub integration automatically collects compliance evidence from your GitHub organization. Once connected, it continuously monitors your organization's security settings, access controls, and code security features, gathering evidence that satisfies controls for SOC 2 and ISO 27001 compliance frameworks. Key Benefits - Automated evidence collection - No more manual screenshots or exports - Compliance-focused collection - Evidence collected on schedule (weekly or monthly) - Auto-verification - Most evidence sources are automatically checked against compliance rules - Multi-framework support - Single integration satisfies controls across SOC 2 and ISO 27001 Security Model - Read-only access - Humadroid cannot modify your GitHub organization or repositories - GitHub App authentication - Secure, fine-grained permissions per repository - Installation tokens - Short-lived tokens (1 hour) instead of persistent OAuth tokens - External ID protection - Unique installation ID prevents unauthorized access - Full audit trail - All API calls can be tracked in GitHub's audit log (Enterprise) Evidence Sources The GitHub integration collects 12 distinct evidence types across four categories: Organization & Access Management Organization 2FA Status - Description: Verifies 2FA is required and enabled for all organization members - Frequency: Monthly - Auto-Verify: Yes Organization Members - Description: Lists all organization members with roles and activity - Frequency: Monthly - Auto-Verify: No Team Permissions - Description: Documents team membership and repository access - Frequency: Monthly - Auto-Verify: No Outside Collaborators - Description: Lists external users with repository access - Frequency: Monthly - Auto-Verify: Yes Repository Security Branch Protection Rules - Description: Collects branch protection settings for all repositories - Frequency: Monthly - Auto-Verify: Yes Repository Visibility - Description: Inventories repository visibility (public/private/internal) - Frequency: Monthly - Auto-Verify: Yes Required Reviews - Description: Collects pull request review requirements by repository - Frequency: Monthly - Auto-Verify: Yes Deploy Keys - Description: Audits SSH deploy keys across repositories - Frequency: Monthly - Auto-Verify: Yes Security Scanning Secret Scanning - Description: Verifies secret scanning is enabled and checks for alerts - Frequency: Monthly - Auto-Verify: Yes Dependabot Alerts - Description: Collects Dependabot configuration and vulnerability alerts - Frequency: Monthly - Auto-Verify: Yes Code Scanning - Description: Verifies CodeQL/code scanning is enabled and checks findings - Frequency: Monthly - Auto-Verify: Yes Audit & Logging Audit Log - Description: Collects organization audit log events (Enterprise only) - Frequency: Monthly - Auto-Verify: No SOC 2 Control Coverage The GitHub integration provides evidence for the following SOC 2 (2017) Trust Services Criteria: CC6 - Logical and Physical Access Controls CC6.1 - Logical Access Security The entity implements logical access security software, infrastructure, and architectures to protect information assets - Organization 2FA Status - Multi-factor authentication is required for all members - Organization Members - Complete inventory of users with access - Team Permissions - Access is organized through teams with defined permissions CC6.2 - User Registration and Authorization Prior to issuing system credentials and granting access, the entity registers and authorizes new users - Organization Members - Complete inventory of all registered users - Outside Collaborators - External users are tracked and authorized CC6.3 - Removal of Access Rights The entity removes credentials and disables system access when no longer required - Audit Log - Access changes are logged (Enterprise) - Organization Members - Current membership can be compared over time CC6.6 - Logical Access Security Measures The entity implements controls to prevent or detect and act upon unauthorized logical access - Branch Protection Rules - Code access is controlled through branch protection - Repository Visibility - Repositories are properly classified (public/private) - Deploy Keys - SSH keys for automated access are tracked CC7 - System Operations CC7.1 - Security Monitoring The entity monitors system components for anomalies and security events - Secret Scanning - Leaked secrets are detected automatically - Dependabot Alerts - Vulnerable dependencies are identified - Code Scanning - Security vulnerabilities in code are detected CC7.2 - Security Event Logging The entity identifies and logs security events - Audit Log - Security-relevant events are logged (Enterprise) CC7.3 - Security Incident Response The entity evaluates security events and responds to identified incidents - Secret Scanning - Leaked secrets are identified for remediation - Dependabot Alerts - Vulnerabilities are tracked for response - Code Scanning - Code security issues are tracked for resolution CC8 - Change Management CC8.1 - Change Management The entity authorizes, documents, and controls infrastructure changes - Branch Protection Rules - Code changes require specific workflows - Required Reviews - Changes require peer review before merge - Code Scanning - Automated security validation of changes ISO 27001:2022 Control Coverage The GitHub integration provides evidence for the following ISO 27001:2022 Annex A controls: A.5 - Organizational Controls A.5.15 - Access Control Rules to control physical and logical access to information and other associated assets shall be established and implemented - Organization 2FA Status - Strong authentication is enforced - Organization Members - Access is granted to authorized users - Team Permissions - Access is organized through teams A.5.16 - Identity Management The full life cycle of identities shall be managed - Organization Members - Complete inventory of identities A.5.17 - Authentication Information Allocation and management of authentication information shall be controlled - Organization 2FA Status - 2FA is properly configured A.5.18 - Access Rights Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed - Audit Log - Access changes are logged (Enterprise) - Outside Collaborators - External access is tracked - Team Permissions - Team-based access is documented A.8 - Technological Controls A.8.3 - Information Access Restriction Access to information and other associated assets shall be restricted - Branch Protection Rules - Code access is restricted - Repository Visibility - Data exposure is controlled A.8.9 - Configuration Management Configurations shall be established, documented, implemented, monitored and reviewed - Branch Protection Rules - Security configurations are documented A.8.12 - Data Leakage Prevention Data leakage prevention measures shall be applied - Secret Scanning - Secrets in code are detected - Repository Visibility - Public exposure is monitored - Dependabot Alerts - Vulnerable code is identified A.8.15 - Logging Logs that record activities shall be produced, stored, protected and analysed - Audit Log - Organization activity is logged (Enterprise) A.8.16 - Monitoring Activities Networks, systems and applications shall be monitored for anomalous behaviour - Secret Scanning - Secret leakage is monitored - Dependabot Alerts - Vulnerability alerts are monitored - Code Scanning - Code security is continuously monitored A.8.25 - Secure Development Life Cycle Rules for the secure development of software and systems shall be established and applied - Branch Protection Rules - Development workflows are enforced - Required Reviews - Code review is required - Code Scanning - Security testing is automated A.8.28 - Secure Coding Secure coding principles shall be applied to software development - Code Scanning - Security vulnerabilities are detected - Dependabot Alerts - Insecure dependencies are identified - Secret Scanning - Hardcoded secrets are detected A.8.31 - Separation of Development, Test and Production Environments Development, testing and production environments shall be separated and secured - Branch Protection Rules - Branch policies enforce environment separation - Repository Visibility - Repository access is properly segmented Verification Rules Auto-verified evidence sources are checked against the following compliance thresholds: Organization 2FA Status - 2FA required for organization: Required - Member 2FA coverage: 100% - Maximum organization owners: 5 (configurable) Branch Protection - Default branch protected: 100% (for applicable repos) - Require pull requests: Required - Required approving reviews: 1+ - Dismiss stale reviews: Recommended - Enforce on administrators: Recommended - Require status checks: Recommended Repository Visibility - Allow public repositories: No (configurable) - Maximum public repositories: 0 (configurable) Required Reviews - Reviews required coverage: 100% - Minimum reviewers: 1 Secret Scanning - Secret scanning enabled: 100% - Push protection enabled: Recommended - Maximum open alerts: 0 Dependabot - Dependabot enabled: 100% - Maximum critical alerts: 0 - Maximum high alerts: 0 (configurable) - Auto security updates: Recommended Code Scanning - Code scanning enabled: 80% (configurable) - Maximum critical alerts: 0 - Maximum high alerts: 0 (configurable) Deploy Keys - Maximum key age: 90 days (configurable) - Read-only keys preferred: Recommended Outside Collaborators - Maximum collaborators with admin: 0 - All collaborators documented: Required Summary: Control Coverage Matrix SOC 2 Controls by Evidence Source Organization 2FA Status - CC6.1: Yes Organization Members - CC6.1: Yes - CC6.2: Yes - CC6.3: Yes Team Permissions - CC6.1: Yes Outside Collaborators - CC6.2: Yes Branch Protection - CC6.6: Yes - CC8.1: Yes Repository Visibility - CC6.6: Yes Required Reviews - CC8.1: Yes Deploy Keys - CC6.6: Yes Secret Scanning - CC7.1: Yes - CC7.3: Yes Dependabot Alerts - CC7.1: Yes - CC7.3: Yes Code Scanning - CC7.1: Yes - CC7.3: Yes - CC8.1: Yes Audit Log - CC6.3: Yes - CC7.2: Yes ISO 27001 Controls by Evidence Source Organization 2FA Status - A.5.15: Yes - A.5.17: Yes Organization Members - A.5.15: Yes - A.5.16: Yes Team Permissions - A.5.15: Yes - A.5.18: Yes Outside Collaborators - A.5.18: Yes Branch Protection - A.8.3: Yes - A.8.9: Yes - A.8.25: Yes - A.8.31: Yes Repository Visibility - A.8.3: Yes - A.8.12: Yes - A.8.31: Yes Required Reviews - A.8.25: Yes Deploy Keys - (No specific ISO 27001 controls mapped) Secret Scanning - A.8.12: Yes - A.8.16: Yes - A.8.28: Yes Dependabot Alerts - A.8.12: Yes - A.8.16: Yes - A.8.28: Yes Code Scanning - A.8.16: Yes - A.8.25: Yes - A.8.28: Yes Audit Log - A.5.18: Yes - A.8.15: Yes Getting Started To set up the GitHub integration: 1. Navigate to Settings > Integrations > GitHub 2. Click Install GitHub App 3. Select your GitHub organization 4. Choose repository access (all repositories recommended) 5. Approve the permissions 6. Enable evidence sources for your compliance controls For detailed setup instructions, see the GitHub App Setup Guide. GitHub Permissions Required The integration uses a GitHub App with the following permissions: Repository Permissions (Read-only) Administration - Description: Branch protection, settings - Used For: Branch protection rules, repo configuration Metadata - Description: Basic repository information - Used For: Repository listing (auto-granted) Secret scanning alerts - Description: View secret scanning alerts - Used For: Secret scanning status and alerts Dependabot alerts - Description: View Dependabot alerts - Used For: Vulnerability monitoring Code scanning alerts - Description: View code scanning alerts - Used For: CodeQL and security findings Organization Permissions (Read-only) Members - Description: Organization membership - Used For: Member listing, 2FA status Administration - Description: Organization settings - Used For: 2FA requirement, org configuration GitHub Plan Feature Matrix Free Plan - Organization 2FA enforcement: Yes - Branch protection: Yes - Required reviews: Yes - Secret scanning (public repos): Yes - Secret scanning (private repos): No - Push protection: No - Dependabot alerts: Yes - Code scanning: Yes - Audit log (web UI): No - Audit log (API): No - IP allow lists: No - SAML SSO: No Team Plan - Organization 2FA enforcement: Yes - Branch protection: Yes - Required reviews: Yes - Secret scanning (public repos): Yes - Secret scanning (private repos): Yes* - Push protection: Yes* - Dependabot alerts: Yes - Code scanning: Yes - Audit log (web UI): Yes - Audit log (API): No - IP allow lists: No - SAML SSO: No *Requires GitHub Advanced Security add-on Enterprise Plan - Organization 2FA enforcement: Yes - Branch protection: Yes - Required reviews: Yes - Secret scanning (public repos): Yes - Secret scanning (private repos): Yes - Push protection: Yes - Dependabot alerts: Yes - Code scanning: Yes - Audit log (web UI): Yes - Audit log (API): Yes - IP allow lists: Yes - SAML SSO: Yes Support If you need help with your GitHub integration: - Email: support@humadroid.com - Status: https://status.humadroid.com

Cloudflare integration guide

Overview Humadroid's Cloudflare integration automatically collects compliance evidence from your Cloudflare account. Once connected, it continuously monitors your zones' security configurations, SSL/TLS settings, WAF rules, and DDoS protection, gathering evidence that satisfies controls for SOC 2 and ISO 27001 compliance frameworks. Key Benefits - Automated evidence collection - No more manual screenshots or exports - Compliance-focused collection - Evidence collected on schedule (daily or weekly) - Auto-verification - All evidence sources are automatically checked against compliance rules - Multi-framework support - Single integration satisfies controls across SOC 2 and ISO 27001 Security Model - Read-only access - Humadroid cannot modify your Cloudflare configuration - API token authentication - Fine-grained, scoped API tokens instead of global API keys - Zone-level permissions - Access limited to selected zones - Full audit trail - All API calls can be tracked in Cloudflare's audit log (Business+ plans) Evidence Sources The Cloudflare integration collects 11 distinct evidence types across four categories: SSL/TLS & Encryption SSL/TLS Mode - Description: Verifies SSL/TLS encryption mode for all zones (off, flexible, full, strict) - Frequency: Daily - Auto-Verify: Yes Minimum TLS Version - Description: Verifies minimum TLS version setting for all zones - Frequency: Daily - Auto-Verify: Yes HSTS Configuration - Description: Collects HTTP Strict Transport Security settings including max-age, includeSubDomains, and preload - Frequency: Daily - Auto-Verify: Yes Certificate Status - Description: Monitors SSL certificate validity and expiration status - Frequency: Daily - Auto-Verify: Yes Web Application Firewall WAF Configuration - Description: Collects WAF configuration including managed rules, custom rules, and security settings - Frequency: Daily - Auto-Verify: Yes Access Rules - Description: Collects IP access rules and firewall access control configurations - Frequency: Daily - Auto-Verify: Yes DDoS & Bot Protection DDoS Protection Status - Description: Verifies DDoS protection is enabled (always on for Cloudflare-proxied traffic) - Frequency: Daily - Auto-Verify: Yes Rate Limiting Rules - Description: Collects rate limiting rule configurations - Frequency: Daily - Auto-Verify: Yes Bot Protection Status - Description: Collects bot protection settings including bot fight mode and managed bot protection - Frequency: Daily - Auto-Verify: Yes DNS Security DNSSEC Status - Description: Verifies DNSSEC is enabled for DNS security - Frequency: Daily - Auto-Verify: Yes Security Headers - Description: Collects security header configurations (HSTS, X-Content-Type-Options, X-Frame-Options) - Frequency: Daily - Auto-Verify: Yes SOC 2 Control Coverage The Cloudflare integration provides evidence for the following SOC 2 (2017) Trust Services Criteria: CC6 - Logical and Physical Access Controls CC6.1 - Logical Access Security The entity implements logical access security software, infrastructure, and architectures to protect information assets - SSL/TLS Mode - End-to-end encryption protects data in transit - TLS Version - Modern TLS protocols prevent protocol downgrade attacks - Certificate Status - Valid certificates ensure secure connections CC6.6 - Logical Access Security Measures The entity implements controls to prevent or detect and act upon unauthorized logical access - WAF Configuration - Web Application Firewall blocks malicious traffic - Access Rules - IP-based access controls restrict unauthorized access - Rate Limiting - Prevents brute force and credential stuffing attacks - Bot Protection - Detects and blocks malicious bot traffic - Security Headers - Prevents clickjacking and content-type attacks CC6.7 - Data Transmission Controls The entity restricts transmission and movement of data - SSL/TLS Mode - Encryption protects data during transmission - TLS Version - Strong protocols ensure secure data transfer - HSTS Configuration - Forces HTTPS to prevent downgrade attacks - Certificate Status - Valid certificates ensure data integrity CC7 - System Operations CC7.1 - Security Monitoring The entity monitors system components for anomalies and security events - WAF Configuration - Monitors and logs security threats - Bot Protection - Monitors for malicious bot activity - DDoS Protection - Monitors for DDoS attacks A1 - Availability A1.2 - Recovery Procedures The entity's recovery procedures support system recovery in accordance with recovery objectives - DDoS Protection - Mitigates availability attacks - DNSSEC Status - Protects DNS integrity to ensure availability ISO 27001:2022 Control Coverage The Cloudflare integration provides evidence for the following ISO 27001:2022 Annex A controls: A.5 - Organizational Controls A.5.15 - Access Control Rules to control physical and logical access to information and other associated assets shall be established and implemented - WAF Configuration - Access control via web application firewall - Access Rules - IP-based access restrictions A.8 - Technological Controls A.8.3 - Information Access Restriction Access to information and other associated assets shall be restricted - WAF Configuration - Restricts access to web applications - Access Rules - IP, country, and ASN-based access controls A.8.20 - Networks Security Networks and network devices shall be secured, managed and controlled - WAF Configuration - Web application layer security - DDoS Protection - Network-level attack protection - Rate Limiting - Network traffic controls - Bot Protection - Automated traffic filtering - DNSSEC Status - DNS security extensions - Security Headers - HTTP security headers A.8.24 - Use of Cryptography Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented - SSL/TLS Mode - Encryption mode configuration - TLS Version - Cryptographic protocol version - HSTS Configuration - Enforced HTTPS communication - Certificate Status - Certificate management and validity Verification Rules Auto-verified evidence sources are checked against the following compliance thresholds: SSL/TLS Mode - Minimum SSL mode: Full (configurable) - Options: off, flexible, full, strict - Recommended: Strict TLS Version - Minimum TLS version: 1.2 (configurable) - Options: 1.0, 1.1, 1.2, 1.3 - Recommended: 1.2 or higher HSTS Configuration - HSTS enabled: Required - Include subdomains: Required - Minimum max-age: 31536000 seconds (1 year) - Preload: Recommended (not required by default) Certificate Status - Valid certificate: Required - Minimum days until expiry: 30 days (configurable) - Universal SSL: Recommended WAF Configuration - WAF enabled: Required - Managed rules configured: Required DDoS Protection - DDoS protection active: Required (automatic for proxied zones) Rate Limiting - Rate limiting configured: Recommended (not required by default) Bot Protection - Bot protection enabled: Required (bot management or browser check) - Advanced Bot Management: Not required by default DNSSEC Status - DNSSEC enabled: Required Access Rules - Block rules configured: Recommended (not required by default) Security Headers - HSTS header: Required - X-Content-Type-Options: Required - X-Frame-Options: Recommended (not required by default) Summary: Control Coverage Matrix SOC 2 Controls by Evidence Source SSL/TLS Mode - CC6.1: Yes - CC6.7: Yes TLS Version - CC6.1: Yes - CC6.7: Yes HSTS Configuration - CC6.7: Yes Certificate Status - CC6.1: Yes - CC6.7: Yes WAF Configuration - CC6.6: Yes - CC7.1: Yes Access Rules - CC6.6: Yes DDoS Protection - CC6.6: Yes - CC7.1: Yes - A1.2: Yes Rate Limiting - CC6.6: Yes Bot Protection - CC6.6: Yes - CC7.1: Yes DNSSEC Status - A1.2: Yes Security Headers - CC6.6: Yes ISO 27001 Controls by Evidence Source SSL/TLS Mode - A.8.24: Yes TLS Version - A.8.24: Yes HSTS Configuration - A.8.24: Yes Certificate Status - A.8.24: Yes WAF Configuration - A.5.15: Yes - A.8.3: Yes - A.8.20: Yes Access Rules - A.5.15: Yes - A.8.3: Yes DDoS Protection - A.8.20: Yes Rate Limiting - A.8.20: Yes Bot Protection - A.8.20: Yes DNSSEC Status - A.8.20: Yes Security Headers - A.8.20: Yes Getting Started To set up the Cloudflare integration: 1. Navigate to Settings > Integrations > Cloudflare 2. Click Connect Cloudflare Account 3. Create an API token in your Cloudflare dashboard (see permissions below) 4. Paste the API token and validate the connection 5. Select the zones you want to monitor 6. Enable evidence sources for your compliance controls Cloudflare Permissions Required Create a custom API token with the following permissions: Zone Permissions (Read-only) Zone → Zone → Read - Basic zone information for zone listing and status Zone → Zone Settings → Read - Zone configuration for SSL mode, TLS version, HSTS Zone → SSL and Certificates → Read - Certificate information for status and expiry monitoring Zone → Firewall Services → Read - Firewall rules for access rules and rate limiting Zone → WAF → Read - WAF configuration for status and managed rules Zone → DNS → Read - DNS settings for DNSSEC status Account Permissions (Read-only) Account → Account Settings → Read - Account information for verification Setup Instructions 1. Log into your Cloudflare Dashboard 2. Go to Profile → API Tokens → Create Token 3. Click Create Custom Token 4. Name the token "Humadroid Compliance Read-Only" 5. Add the permissions listed above 6. Set Zone Resources: Include all zones (or specific zones) 7. Create the token and copy it to Humadroid Cloudflare Plan Feature Matrix Free Plan Available features: - SSL/TLS Mode - Minimum TLS Version - HSTS Configuration - Certificate Status - DDoS Protection (Always On) - DNSSEC - Basic WAF - Bot Fight Mode - Access Rules - Security Headers Not available: - Rate Limiting (requires Pro+) Pro Plan Includes all Free features, plus: - Rate Limiting (5 rules) - Enhanced WAF - Polish/Mirage Business Plan Includes all Pro features, plus: - Rate Limiting (Unlimited) - Page Shield - Audit Logs - Advanced WAF Enterprise Plan Includes all Business features, plus: - Advanced Bot Management - Logpush - Advanced DDoS Protection - Custom SSL Troubleshooting Common Issues "Permission denied - API token needs 'Zone:WAF:Read' permission" - Your API token is missing the WAF read permission - Edit your token in Cloudflare to add: Zone → WAF → Read "No accounts accessible with this token" - Your token doesn't have account-level read access - Add: Account → Account Settings → Read "Authentication failed" - Check that your API token is correct and hasn't expired - Verify the token has the required permissions Evidence showing 0 for all metrics - Ensure the selected zones have the features enabled - Some features require specific Cloudflare plans Support If you need help with your Cloudflare integration: - Documentation: https://docs.humadroid.com/integrations/cloudflare - Email: support@humadroid.com - Status: https://status.humadroid.com Last updated: January 2026

GCP integration guide

Overview Humadroid's GCP integration automatically collects compliance evidence from your Google Cloud Platform infrastructure. Once connected, it continuously monitors your GCP environment and gathers evidence that satisfies controls for SOC 2 and ISO 27001 compliance frameworks. Key Benefits - Automated evidence collection - No more manual screenshots or exports - Compliance-focused collection - Evidence collected on schedule (weekly or monthly) - Auto-verification - Many evidence sources are automatically checked against compliance rules - Multi-framework support - Single integration satisfies controls across SOC 2 and ISO 27001 Security Model - Read-only access - Humadroid cannot modify your GCP resources - Service Account authentication - Secure credential handling with least-privilege permissions - Encrypted credential storage - Service account keys encrypted at rest - Full audit trail - All API calls logged in your Cloud Audit Logs Evidence Sources The GCP integration collects 15 distinct evidence types across six categories: Identity & Access Management IAM Policy - Description: Documents IAM policy bindings and role assignments across the project - Frequency: Monthly - Auto-Verify: Yes IAM Service Accounts - Description: Inventories all service accounts with keys and usage patterns - Frequency: Monthly - Auto-Verify: Yes IAM MFA Status - Description: Verifies multi-factor authentication enforcement for users - Frequency: Monthly - Auto-Verify: Yes Logging & Monitoring Audit Logs Status - Description: Verifies Cloud Audit Logs are enabled and properly configured - Frequency: Monthly - Auto-Verify: Yes Audit Log Events - Description: Audit trail of API calls and administrative events - Frequency: Monthly - Auto-Verify: No Monitoring Alerts - Description: Cloud Monitoring alert policies configuration - Frequency: Monthly - Auto-Verify: Yes VPC Flow Logs - Description: Network traffic logging configuration for VPCs - Frequency: Monthly - Auto-Verify: Yes Security Services Security Findings - Description: Security Command Center findings and threat detection - Frequency: Weekly - Auto-Verify: No Network Security Firewall Rules - Description: VPC firewall rules configuration and security analysis - Frequency: Monthly - Auto-Verify: Yes Encryption & Data Protection Storage Encryption - Description: Verifies Cloud Storage buckets have encryption enabled - Frequency: Monthly - Auto-Verify: Yes Storage Public Access - Description: Verifies Cloud Storage buckets block public access - Frequency: Monthly - Auto-Verify: Yes SQL Encryption - Description: Verifies Cloud SQL instances have encryption enabled - Frequency: Monthly - Auto-Verify: Yes Compute Encryption - Description: Verifies Compute Engine disks are encrypted - Frequency: Monthly - Auto-Verify: Yes KMS Key Rotation - Description: Verifies Cloud KMS keys are configured for automatic rotation - Frequency: Monthly - Auto-Verify: Yes Backup & Recovery SQL Backups - Description: Cloud SQL backup execution and configuration monitoring - Frequency: Weekly - Auto-Verify: Yes SOC 2 Control Coverage The GCP integration provides evidence for the following SOC 2 (2017) Trust Services Criteria: CC6 - Logical and Physical Access Controls CC6.1 - Logical Access Security The entity implements logical access security software, infrastructure, and architectures to protect information assets - IAM Policy - Access policies enforce least-privilege principles - IAM MFA Status - Multi-factor authentication is enforced - IAM Service Accounts - Service account credentials are properly managed - Storage Encryption - Data at rest is encrypted - SQL Encryption - Databases are encrypted - Compute Encryption - Compute disks are encrypted - KMS Key Rotation - Encryption keys are properly rotated CC6.2 - User Registration and Authorization Prior to issuing system credentials and granting access, the entity registers and authorizes new users - IAM Policy - Complete inventory of users with access and role bindings - IAM Service Accounts - Service account creation and authorization records CC6.3 - Removal of Access Rights The entity removes credentials and disables system access when no longer required - Audit Log Events - Access revocation events are logged - IAM Service Accounts - Inactive or unused service accounts identified CC6.6 - Logical Access Security Measures The entity implements controls to prevent or detect and act upon unauthorized logical access - Firewall Rules - VPC firewall rules restrict access appropriately - VPC Flow Logs - Network traffic is monitored - Storage Public Access - Storage buckets are not publicly exposed CC6.7 - Data Transmission Controls The entity restricts transmission and movement of data - Storage Encryption - Data is encrypted during storage and transfer - SQL Encryption - Database data is encrypted - Compute Encryption - Compute disks are encrypted - KMS Key Rotation - Encryption keys are managed securely CC7 - System Operations CC7.1 - Security Monitoring The entity monitors system components for anomalies and security events - Security Findings - Security Command Center detects threats - Monitoring Alerts - Alerts are configured for security events CC7.2 - Security Event Logging The entity identifies and logs security events - Audit Logs Status - Audit logging is properly configured - Audit Log Events - Security events are recorded - VPC Flow Logs - Network activity is logged CC7.3 - Security Incident Response The entity evaluates security events and responds to identified incidents - Security Findings - Threats are detected and tracked - Monitoring Alerts - Incident alerts are configured CC7.4 - Security Alerting The entity implements alerting mechanisms for security events - Monitoring Alerts - Alert policies are configured and active CC8 - Change Management CC8.1 - Change Management The entity authorizes, documents, and controls infrastructure changes - Audit Log Events - Infrastructure changes are logged A1 - Availability A1.2 - Recovery Procedures The entity's recovery procedures support system recovery in accordance with recovery objectives - SQL Backups - Database backups are maintained and executed successfully ISO 27001:2022 Control Coverage The GCP integration provides evidence for the following ISO 27001:2022 Annex A controls: A.5 - Organizational Controls A.5.15 - Access Control Rules to control physical and logical access to information and other associated assets shall be established and implemented - IAM Policy - Access policies enforce security requirements - IAM MFA Status - Strong authentication is required - IAM Service Accounts - Service account access is managed - Firewall Rules - Network access is controlled A.5.16 - Identity Management The full life cycle of identities shall be managed - IAM Policy - Complete inventory of identities - IAM Service Accounts - Service account lifecycle management A.5.17 - Authentication Information Allocation and management of authentication information shall be controlled - IAM MFA Status - MFA is properly configured - IAM Service Accounts - Service account keys are managed A.5.18 - Access Rights Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed - IAM Service Accounts - Service account access is reviewed - Audit Log Events - Access changes are logged A.5.23 - Cloud Services Security Processes for acquisition, use, management and exit from cloud services shall be established - Security Findings - Cloud threat detection is active - Audit Logs Status - Cloud activity is logged A.8 - Technological Controls A.8.3 - Information Access Restriction Access to information and other associated assets shall be restricted - Storage Public Access - Data is not publicly accessible - Firewall Rules - Network access is restricted A.8.9 - Configuration Management Configurations, including security configurations, shall be established, documented, implemented, monitored and reviewed - Firewall Rules - Security configurations are documented A.8.12 - Data Leakage Prevention Data leakage prevention measures shall be applied - Storage Public Access - Public exposure is prevented - Security Findings - Data exfiltration attempts are detected - VPC Flow Logs - Data transfers are monitored A.8.13 - Information Backup Backup copies of information, software and systems shall be maintained and regularly tested - SQL Backups - Backups are executed regularly A.8.15 - Logging Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed - Audit Logs Status - API activity is logged - VPC Flow Logs - Network activity is logged - Monitoring Alerts - Logs are monitored for anomalies A.8.16 - Monitoring Activities Networks, systems and applications shall be monitored for anomalous behaviour - Security Findings - Threat monitoring is active - Monitoring Alerts - System monitoring is configured A.8.20 - Networks Security Networks and network devices shall be secured, managed and controlled - Firewall Rules - Network security rules are configured - VPC Flow Logs - Network traffic is monitored A.8.24 - Use of Cryptography Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented - Storage Encryption - Cloud Storage is encrypted - SQL Encryption - Databases are encrypted - Compute Encryption - Compute disks are encrypted - KMS Key Rotation - Encryption keys are rotated Verification Rules Auto-verified evidence sources are checked against the following compliance thresholds: IAM Policy - Overly permissive roles: Flagged - Primitive roles (Owner/Editor): Flagged for review - External members: Documented IAM Service Accounts - Maximum key age: 90 days - Unused service accounts: Flagged - User-managed keys: Documented IAM MFA Status - MFA enforcement: Required - Organization policy: Should enforce MFA Audit Logs Status - Admin Activity logs: Required (always on) - Data Access logs: Recommended - Log retention: 400+ days recommended Storage Security - All buckets encrypted: Required (default in GCP) - Customer-managed keys (CMEK): Recommended - Public access blocked: Required - Uniform bucket-level access: Recommended SQL Security - All instances encrypted: Required - Automated backups enabled: Required - Backup retention period: 7+ days - SSL/TLS required: Recommended Network Security - No open SSH (0.0.0.0/0:22): Required - No open RDP (0.0.0.0/0:3389): Required - VPC Flow Logs enabled: Required - Default deny rules: Recommended KMS Key Rotation - Automatic rotation enabled: Required - Rotation period: 90 days recommended Security Services - Security Command Center enabled: Recommended - Cloud Monitoring alerts configured: Recommended Summary: Control Coverage Matrix SOC 2 Controls by Evidence Source IAM Policy - CC6.1: Yes - CC6.2: Yes IAM Service Accounts - CC6.1: Yes - CC6.2: Yes - CC6.3: Yes IAM MFA Status - CC6.1: Yes Audit Logs Status - CC7.2: Yes Audit Log Events - CC6.3: Yes - CC7.2: Yes - CC8.1: Yes Monitoring Alerts - CC7.1: Yes - CC7.3: Yes - CC7.4: Yes VPC Flow Logs - CC6.6: Yes - CC7.2: Yes Security Findings - CC7.1: Yes - CC7.3: Yes Firewall Rules - CC6.6: Yes Storage Encryption - CC6.1: Yes - CC6.7: Yes Storage Public Access - CC6.6: Yes SQL Encryption - CC6.1: Yes - CC6.7: Yes Compute Encryption - CC6.1: Yes - CC6.7: Yes KMS Key Rotation - CC6.1: Yes - CC6.7: Yes SQL Backups - A1.2: Yes ISO 27001 Controls by Evidence Source IAM Policy - A.5.15: Yes - A.5.16: Yes IAM Service Accounts - A.5.15: Yes - A.5.16: Yes - A.5.17: Yes - A.5.18: Yes IAM MFA Status - A.5.15: Yes - A.5.17: Yes Audit Logs Status - A.5.23: Yes - A.8.15: Yes Audit Log Events - A.5.18: Yes Monitoring Alerts - A.8.15: Yes - A.8.16: Yes VPC Flow Logs - A.8.12: Yes - A.8.15: Yes - A.8.20: Yes Security Findings - A.5.23: Yes - A.8.12: Yes - A.8.16: Yes Firewall Rules - A.5.15: Yes - A.8.3: Yes - A.8.9: Yes - A.8.20: Yes Storage Encryption - A.8.24: Yes Storage Public Access - A.8.3: Yes - A.8.12: Yes SQL Encryption - A.8.24: Yes Compute Encryption - A.8.24: Yes KMS Key Rotation - A.8.24: Yes SQL Backups - A.8.13: Yes Getting Started To set up the GCP integration: 1. Navigate to Settings > Integrations > GCP 2. Click Connect GCP Project 3. Follow the setup wizard to create a Service Account in your GCP project 4. Download and upload the Service Account JSON key 5. Validate the connection 6. Enable evidence sources for your compliance controls For detailed setup instructions, see the GCP Setup Guide. GCP Permissions Required The integration requires read-only permissions via a Service Account with the following roles: Recommended Roles - Security Reviewer (roles/iam.securityReviewer) - Viewer (roles/viewer) - Cloud Asset Viewer (roles/cloudasset.viewer) Core Permissions resourcemanager.projects.get resourcemanager.projects.getIamPolicy iam.serviceAccounts.list iam.serviceAccounts.get iam.roles.list logging.logEntries.list logging.sinks.list cloudkms.cryptoKeys.list cloudkms.cryptoKeys.get cloudkms.keyRings.list storage.buckets.list storage.buckets.get storage.buckets.getIamPolicy cloudsql.instances.list cloudsql.backupRuns.list compute.instances.list compute.disks.list compute.firewalls.list compute.subnetworks.list compute.networks.list securitycenter.findings.list securitycenter.sources.list monitoring.alertPolicies.list cloudasset.assets.searchAllResources GCP Service Feature Matrix Standard GCP Project - IAM policy audit: Yes - Service account inventory: Yes - Firewall rules audit: Yes - Storage encryption check: Yes - Storage public access check: Yes - Cloud SQL encryption: Yes - Cloud SQL backups: Yes - Compute disk encryption: Yes - KMS key rotation: Yes - VPC Flow Logs: Yes - Cloud Audit Logs: Yes - Security Command Center: Requires activation - Cloud Monitoring: Yes Organization-Level Features Some features provide enhanced coverage at the organization level: - Organization-wide IAM policies - Cross-project security findings - Centralized audit log aggregation - Organization policy constraints Note: Organization-level features require additional permissions at the organization level.

Vercel Integration User Guide

Overview Humadroid's Vercel integration automatically collects compliance evidence from your Vercel deployment platform. Once connected, it continuously monitors your Vercel team configuration, project settings, and security controls to gather evidence that satisfies controls for SOC 2 and ISO 27001 compliance frameworks. Key Benefits - Automated evidence collection - No more manual screenshots or exports - Compliance-focused collection - Evidence collected on schedule (monthly) - Auto-verification - Many evidence sources are automatically checked against compliance rules - Multi-framework support - Single integration satisfies controls across SOC 2 and ISO 27001 - Plan-aware - Automatically adapts to your Vercel plan (Hobby/Pro/Enterprise) Security Model - Read-only access - Humadroid cannot modify your Vercel settings or deployments - Dual authentication options - OAuth integration (recommended) or API Token - Team-scoped access - Access limited to selected team only - Encrypted credential storage - Credentials encrypted at rest - Easily revocable - Disconnect anytime from Humadroid or revoke from Vercel Evidence Sources The Vercel integration collects 9 distinct evidence types across three categories: Access Control Team Members & Roles - Description: Collects team membership and role assignments for access control evidence - Frequency: Monthly - Auto-Verify: Yes - Plan Required: All plans RBAC Configuration - Description: Documents role-based access control configuration and custom roles - Frequency: Monthly - Auto-Verify: Yes - Plan Required: All plans Project Access Settings - Description: Collects project-level access restrictions and team assignments - Frequency: Monthly - Auto-Verify: Yes - Plan Required: All plans SSO/SAML Configuration - Description: Collects SSO enforcement status and SAML configuration - Frequency: Monthly - Auto-Verify: Yes - Plan Required: Enterprise only Deployment Security Deployment Protection - Description: Collects deployment protection settings including authentication requirements - Frequency: Monthly - Auto-Verify: Yes - Plan Required: All plans (limited on Hobby) Network Security Firewall Status - Description: Collects firewall enablement and managed rulesets (Bot Protection, AI Bots) across projects - Frequency: Monthly - Auto-Verify: Yes - Plan Required: Pro+ WAF Rules - Description: Collects custom WAF rules and managed rule configurations - Frequency: Monthly - Auto-Verify: No (manual review recommended) - Plan Required: Pro+ IP Blocking Rules - Description: Collects IP blocking and allowlist configurations - Frequency: Monthly - Auto-Verify: Yes - Plan Required: All plans (limits vary by plan) Audit & Monitoring Audit Logs - Description: Team activity audit logs for security monitoring - Frequency: Monthly - Auto-Verify: No (manual review required) - Plan Required: Enterprise only SOC 2 Control Coverage The Vercel integration provides evidence for the following SOC 2 (2017) Trust Services Criteria: CC6 - Logical and Physical Access Controls CC6.1 - Logical Access Security The entity implements logical access security software, infrastructure, and architectures to protect information assets - Team Members & Roles - Access policies enforce least-privilege principles - RBAC Configuration - Role-based access controls are properly configured - Project Access Settings - Project-level access is restricted appropriately - SSO/SAML Configuration - Enterprise SSO enforces strong authentication CC6.2 - User Registration and Authorization Prior to issuing system credentials and granting access, the entity registers and authorizes new users - Team Members & Roles - Complete inventory of users with access and role assignments - Audit Logs - User registration and authorization events are logged (Enterprise) CC6.3 - Removal of Access Rights The entity removes credentials and disables system access when no longer required - RBAC Configuration - Role changes and access modifications documented - Audit Logs - Access revocation events are logged (Enterprise) CC6.6 - Logical Access Security Measures The entity implements controls to prevent or detect and act upon unauthorized logical access - Project Access Settings - Project-level access restrictions prevent unauthorized access - Deployment Protection - Deployments are protected from unauthorized access - Firewall Status - Firewall and managed rulesets protect against attacks (Pro+) - WAF Rules - Custom WAF rules provide application-level protection (Pro+) - IP Blocking Rules - Network-level access restrictions are configured CC7 - System Operations CC7.2 - Security Event Logging The entity identifies and logs security events - Audit Logs - Security events are recorded (Enterprise) CC8 - Change Management CC8.1 - Change Management The entity authorizes, documents, and controls infrastructure changes - Deployment Protection - Deployment changes require appropriate authorization - Audit Logs - Infrastructure changes are logged (Enterprise) ISO 27001:2022 Control Coverage The Vercel integration provides evidence for the following ISO 27001:2022 Annex A controls: A.5 - Organizational Controls A.5.15 - Access Control Rules to control physical and logical access to information and other associated assets shall be established and implemented - Team Members & Roles - Access policies enforce security requirements - RBAC Configuration - Role-based access control is implemented - Project Access Settings - Project-level access is controlled - SSO/SAML Configuration - Strong authentication is enforced (Enterprise) A.5.16 - Identity Management The full life cycle of identities shall be managed - Team Members & Roles - Complete inventory of identities - Audit Logs - Identity lifecycle events are tracked (Enterprise) A.5.17 - Authentication Information Allocation and management of authentication information shall be controlled - SSO/SAML Configuration - Authentication is properly configured (Enterprise) - Deployment Protection - Deployment authentication requirements A.5.18 - Access Rights Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed - RBAC Configuration - Access rights are managed through roles - Audit Logs - Access changes are logged (Enterprise) A.5.23 - Information Security for Use of Cloud Services Processes for acquisition, use, management and exit from cloud services shall be established - Firewall Status - Cloud security controls are configured (Pro+) - Deployment Protection - Cloud deployments are protected - Audit Logs - Cloud service usage is logged (Enterprise) A.8 - Technological Controls A.8.3 - Information Access Restriction Access to information and other associated assets shall be restricted - Project Access Settings - Project data access is restricted - Deployment Protection - Deployment access is controlled - IP Blocking Rules - Network access is restricted A.8.9 - Configuration Management Configurations, including security configurations, shall be established, documented, implemented, monitored and reviewed - Firewall Status - Security configurations are documented (Pro+) - WAF Rules - Custom security rules are configured (Pro+) A.8.12 - Data Leakage Prevention Data leakage prevention measures shall be applied - Deployment Protection - Unauthorized access to deployments is prevented A.8.15 - Logging Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed - Audit Logs - Activity logs are maintained (Enterprise) A.8.16 - Monitoring Activities Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken - Firewall Status - Security monitoring via firewall (Pro+) A.8.20 - Networks Security Networks and network devices shall be secured, managed and controlled - Firewall Status - Firewall provides network protection (Pro+) - WAF Rules - Network security rules are configured (Pro+) - IP Blocking Rules - Network access is controlled A.8.21 - Security of Network Services Security mechanisms, service levels and service requirements of network services shall be identified, implemented and monitored - Firewall Status - Network service security is monitored (Pro+) - IP Blocking Rules - Network service access is controlled Verification Rules Auto-verified evidence sources are checked against the following compliance thresholds: Team Members & Roles - All team members have assigned roles: Required - No orphaned or inactive members: Flagged - Admin role usage: Documented and reviewed RBAC Configuration - Custom roles follow least-privilege: Recommended - Role assignments documented: Required - Sensitive permissions (billing, team management): Flagged for review Project Access Settings - Project access restricted to authorized teams: Required - No overly permissive project settings: Flagged - Production project restrictions: Recommended Deployment Protection - Production environments protected: Required - Authentication required for preview deployments: Recommended - Password protection configured: Optional SSO/SAML Configuration (Enterprise) - SSO enforcement enabled: Required - SAML configuration valid: Required - Identity provider properly configured: Required Firewall Status (Pro+) - Firewall enabled on production projects: Required - Bot Protection managed ruleset enabled: Recommended - All public-facing projects protected: Required WAF Rules (Pro+) - OWASP Core Rule Set enabled: Recommended - Custom rules reviewed: Manual verification - Rule exceptions documented: Required IP Blocking Rules - Blocking rules configured: Optional - Allowlist properly scoped: Recommended - Geographic restrictions (if applicable): Documented Audit Logs (Enterprise) - Audit logging enabled: Required - Log retention appropriate: Recommended - Regular log review: Manual verification Summary: Control Coverage Matrix SOC 2 Controls by Evidence Source Team Members & Roles - CC6.1: Yes - CC6.2: Yes RBAC Configuration - CC6.1: Yes - CC6.3: Yes Project Access Settings - CC6.1: Yes - CC6.6: Yes Deployment Protection - CC6.6: Yes - CC8.1: Yes SSO/SAML Configuration (Enterprise) - CC6.1: Yes Firewall Status (Pro+) - CC6.6: Yes WAF Rules (Pro+) - CC6.6: Yes IP Blocking Rules - CC6.6: Yes Audit Logs (Enterprise) - CC6.2: Yes - CC6.3: Yes - CC7.2: Yes - CC8.1: Yes ISO 27001 Controls by Evidence Source Team Members & Roles - A.5.15: Yes - A.5.16: Yes RBAC Configuration - A.5.15: Yes - A.5.18: Yes Project Access Settings - A.5.15: Yes - A.8.3: Yes Deployment Protection - A.5.17: Yes - A.5.23: Yes - A.8.3: Yes - A.8.12: Yes SSO/SAML Configuration (Enterprise) - A.5.15: Yes - A.5.17: Yes Firewall Status (Pro+) - A.5.23: Yes - A.8.9: Yes - A.8.16: Yes - A.8.20: Yes - A.8.21: Yes WAF Rules (Pro+) - A.8.9: Yes - A.8.20: Yes IP Blocking Rules - A.8.3: Yes - A.8.20: Yes - A.8.21: Yes Audit Logs (Enterprise) - A.5.16: Yes - A.5.18: Yes - A.5.23: Yes - A.8.15: Yes Additional ISO 27001 Control Coverage A.5.23 - Cloud Services Security - Firewall Status (Pro+): Yes - Deployment Protection: Yes - Audit Logs (Enterprise): Yes A.8.16 - Monitoring Activities - Firewall Status (Pro+): Yes A.8.21 - Security of Network Services - Firewall Status (Pro+): Yes - IP Blocking Rules: Yes Getting Started To set up the Vercel integration: 1. Navigate to Settings > Integrations > Vercel 2. Click Connect Vercel Account 3. Choose your authentication method: - OAuth (Recommended): Click "Connect with Vercel" for one-click authorization - API Token: Manually create and enter a Vercel API token 4. Select the team to monitor (if your account has multiple teams) 5. Validate the connection 6. Enable evidence sources for your compliance controls Option 1: OAuth Connection (Recommended) 1. Click Connect with Vercel button 2. You'll be redirected to Vercel to authorize Humadroid 3. Grant read-only access to your Vercel account 4. You'll be automatically redirected back to Humadroid 5. Select a team if you have multiple teams This method provides automatic token management and scoped permissions. Option 2: API Token (Manual) 1. Log into your Vercel Dashboard 2. Go to Account Settings > Tokens 3. Click Create to create a new token 4. Name: "Humadroid Compliance Read-Only" 5. Scope: Select Full Account for team access 6. Expiration: "No Expiration" recommended for automated collection 7. Click Create Token 8. Copy the token immediately (it won't be shown again) Vercel Permissions Required The integration requires read-only permissions via OAuth or an API Token with Full Account scope: Required Scopes - Team:Read - Access team membership and settings - Projects:Read - Access project configurations - Deployments:Read - Access deployment settings - Firewall:Read - Access WAF and IP blocking rules (Pro+) API Endpoints Used GET /v2/teams - List teams GET /v2/teams/{teamId}/members - List team members GET /v9/projects - List projects GET /v9/projects/{projectId} - Get project details (includes security settings) GET /v6/deployments - List deployments (for protection settings) GET /v1/security/firewall/config - WAF configuration (Enterprise) GET /v2/integrations/sso - SSO configuration (Enterprise) Vercel Plan Feature Matrix Hobby Plan Available Features: - Team Members & Roles - RBAC Configuration (basic roles) - Project Access Settings - Deployment Protection (limited) - IP Blocking Rules (10 IPs max) Not Available: - Firewall Status - WAF Rules - SSO/SAML Configuration - Audit Logs Pro Plan Available Features: - Team Members & Roles - RBAC Configuration - Project Access Settings - Deployment Protection (full features) - IP Blocking Rules (100 IPs max) - Firewall Status - WAF Rules (40 rules max) Not Available: - SSO/SAML Configuration - Audit Logs Enterprise Plan All Features Available: - Team Members & Roles - RBAC Configuration (custom roles) - Project Access Settings - Deployment Protection (full features) - IP Blocking Rules (custom limits) - Firewall Status - WAF Rules (1000 rules max) - SSO/SAML Configuration - Audit Logs - SIEM Streaming - Trusted IPs Troubleshooting Common Issues "Invalid API Token" - Verify the token was copied correctly (no extra spaces) - Check if the token has expired - Ensure the token has Full Account scope "No teams found" - The API token may be personal-only; create a team-scoped token - Verify you have access to at least one team "Firewall data not available" - Firewall features require Pro plan or higher - Ensure the Firewall:Read scope is included "SSO/Audit data not available" - These features require Enterprise plan - Contact Vercel to upgrade if needed Rate Limits Vercel API has the following rate limits: - 10 requests per second - 10,000 requests per day Humadroid respects these limits and implements automatic retry with backoff.

MCP Server — Connect AI Assistants to Humadroid

AuditBadger includes a built-in MCP (Model Context Protocol) server that lets AI assistants use your compliance data directly. This gives AI tools real-time access to your projects, controls, documents, sections, and evidences, plus limited document-editing access when your permissions allow it — so you can ask questions, generate reports, update draft policies, or get implementation guidance without copy-pasting. What you get The MCP server exposes 13 tools: - list_projects / get_project — browse and inspect compliance projects - list_controls / get_control — query controls with filters (by project, section, implementation status) - list_documents / get_document — access policies, procedures, and other compliance documents (including content) - update_document_content — replace the Markdown content of a document; works only on documents in the editable state (finalized documents need a new version created in AuditBadger first) and requires update permission on that document - list_sections / get_section — navigate the section hierarchy within a project - list_evidences / get_evidence — review evidence records - search — full-text search across all compliance data (requires Global Search to be enabled) - send_feedback — send feedback about AuditBadger (bug reports, feature requests, questions) straight to the AuditBadger team; useful when the AI assistant gets stuck and wants to tell us where to improve All data is scoped to your account and respects user permissions. A user connecting via MCP sees exactly the same data they would see in the AuditBadger UI. Prerequisites Before setting up MCP, you need: - API access enabled for your account (an admin must turn this on in Account Settings) - An API token for authentication Step 1: Enable API Access An account administrator must enable API access: 1. Go to Account Settings 2. Find the API Access toggle 3. Enable it and save Without this, all API and MCP requests will be rejected. Step 2: Create an API Token 1. Click your avatar in the top-right corner and go to Profile 2. Navigate to the API Tokens tab 3. Enter a descriptive name for the token (e.g., "Codex MCP") 4. Set an expiration period (up to 30 days) 5. Click Create Token 6. Copy the token immediately — it will only be shown once Keep this token secure. MCP requests use the same account and permission boundaries as your user account, including limited document-update access where allowed. You can revoke the token at any time from the same page. Step 3: Connect your AI assistant Your MCP endpoint URL follows this pattern: https://YOUR-SUBDOMAIN.auditbadger.com/mcp Replace YOUR-SUBDOMAIN with your actual AuditBadger account subdomain (the part before .auditbadger.com when you log in). The server uses the Streamable HTTP transport (the current MCP standard). All clients listed below support it. If you connected before via the legacy /mcp/sse endpoint, update your client configuration — the SSE transport has been retired. Codex (CLI and IDE extension) Codex supports Streamable HTTP MCP servers with bearer-token authentication. The CLI and IDE extension share the same MCP configuration, so one setup works in both clients. For a personal setup, keep the server in ~/.codex/config.toml and store the token in an environment variable: export AUDITBADGER_API_TOKEN="YOUR-API-TOKEN" ​ codex mcp add auditbadger \  --url https://YOUR-SUBDOMAIN.auditbadger.com/mcp \  --bearer-token-env-var AUDITBADGER_API_TOKEN Then verify the server is configured: codex mcp list codex mcp get auditbadger --json You can also edit ~/.codex/config.toml directly: [mcp_servers.auditbadger] url = "https://YOUR-SUBDOMAIN.auditbadger.com/mcp" bearer_token_env_var = "AUDITBADGER_API_TOKEN" For a project-scoped setup, put the same TOML block in .codex/config.toml inside the repo. Keep only the URL and environment-variable name there; do not commit the API token. Codex loads project-scoped .codex/config.toml only for trusted projects. After changing the configuration, start a new Codex session or restart the IDE extension. In the Codex terminal UI, run /mcp to see active MCP servers. Claude Code (CLI) Run this command in your terminal: claude mcp add auditbadger \  --transport http \ https://YOUR-SUBDOMAIN.auditbadger.com/mcp \  --header "Authorization: Bearer YOUR-API-TOKEN" This adds a project-scoped configuration. To share it with your team, add --scope project which writes to .mcp.json at the project root. You can also create .mcp.json manually in your project root: {  "mcpServers": {    "auditbadger": {      "type": "http",      "url": "https://YOUR-SUBDOMAIN.auditbadger.com/mcp",      "headers": {        "Authorization": "Bearer YOUR-API-TOKEN"     }   } } } To use an environment variable instead of a hardcoded token: {  "mcpServers": {    "auditbadger": {      "type": "http",      "url": "https://YOUR-SUBDOMAIN.auditbadger.com/mcp",      "headers": {        "Authorization": "Bearer ${AUDITBADGER_API_TOKEN}"     }   } } } Then set AUDITBADGER_API_TOKEN in your shell environment. After adding, verify with claude mcp list — you should see "auditbadger" listed. Claude Desktop (macOS / Windows app) Claude Desktop's config file only supports local (stdio) servers, and its Connectors UI expects OAuth-based remote servers — AuditBadger uses API-token (Bearer) authentication instead. Use the mcp-remote bridge: The mcp-remote npm package wraps a remote MCP server into a local stdio process that Claude Desktop can use. 1. Make sure you have Node.js installed (v18+) 2. Open Claude, go to Settings, Developer and Edit config OR 1. Open your Claude Desktop config file: 1. macOS: ~/Library/Application Support/Claude/claude_desktop_config.json 2. Windows: %APPDATA%\Claude\claude_desktop_config.json 3. Add the following (replace YOUR-SUBDOMAIN and YOUR-API-TOKEN): {  "mcpServers": {    "auditbadger": {      "command": "npx",      "args": [        "-y",        "mcp-remote",        "https://YOUR-SUBDOMAIN.auditbadger.com/mcp",        "--header",        "Authorization:${AUDITBADGER_TOKEN}"     ],      "env": {        "AUDITBADGER_TOKEN": "Bearer YOUR-API-TOKEN"     }   } } } The token is passed via the env section and referenced as ${AUDITBADGER_TOKEN} in the header argument. The Authorization: header uses no space after the colon — this avoids a known issue where some platforms mangle spaces inside args. 4. Save the file and restart Claude Desktop 5. You should see "auditbadger" in the tools menu (hammer icon) Cursor 1. Create or edit the file .cursor/mcp.json in your project root (or ~/.cursor/mcp.json for global access) 2. Add the following: { "mcpServers": { "auditbadger": { "url": "https://YOUR-SUBDOMAIN.auditbadger.com/mcp", "headers": { "Authorization": "Bearer ${env:AUDITBADGER_API_TOKEN}" } } } } 3. Set the AUDITBADGER_API_TOKEN environment variable to your API token 4. Restart Cursor You can also use the Settings UI: open Settings (Cmd+Shift+P, then "Cursor Settings"), go to the MCP section, and the JSON editor will show the same file. Note: Cursor uses ${env:VAR_NAME} syntax for environment variables (different from Claude Code's ${VAR_NAME} syntax). ChatGPT ChatGPT supports MCP servers through developer mode and connectors. This requires a ChatGPT Pro, Plus, Business, Enterprise, or Education plan. 1. Open ChatGPT on the web 2. Go to Settings then Connectors 3. Click Create to add a new connector 4. Enter the MCP endpoint URL: https://YOUR-SUBDOMAIN.auditbadger.com/mcp 5. Follow the authentication configuration steps Note: ChatGPT connectors may require OAuth-based authentication. If Bearer token auth is not directly supported in the connectors UI, contact your AuditBadger administrator about OAuth setup options. For more details, see OpenAI's documentation on developer mode and MCP connectors. Other MCP Clients Any MCP-compatible client can connect using: - Transport: Streamable HTTP (stateless — every JSON-RPC message is a self-contained POST and the response comes back in the same HTTP response) - Endpoint: https://YOUR-SUBDOMAIN.auditbadger.com/mcp - Authentication: Authorization: Bearer YOUR-API-TOKEN header on all requests Optional: Enable Global Search The MCP server includes a search tool that lets AI assistants search across all your compliance data using full-text search. This is much faster than browsing through lists when looking for specific controls or documents. To enable it: 1. Go to Account Settings 2. Find the Compliance section 3. Enable the Global Search checkbox 4. Save Note: enabling search indexing stores decrypted content (like document text and implementation notes) in a plaintext search index. This enables full-text search but means that data exists in an additional unencrypted form in the database. If Global Search is not enabled, the search tool will return a message telling the AI to use the list tools with filters instead. Usage Examples Once connected, you can ask your AI assistant questions like: - "List all my compliance projects and their status" - "Show me the controls in my ISO 27001 project that are not yet implemented" - "Find the access control policy document and summarize it" - "Rewrite the acceptable use policy to cover remote work, and update the document" - "What evidence do we have for control A.8.1?" - "Search for anything related to encryption in our compliance data" - "Give me a progress report on our SOC 2 project" The AI will use the MCP tools to fetch real-time data from AuditBadger and respond with accurate, up-to-date information. Security and Rate Limits - Data isolation: MCP respects your account boundaries. You can only access data belonging to your account's subdomain. - Permissions: The MCP server enforces the same role-based permissions as the AuditBadger UI. Users see only what they're authorized to see. - Token expiration: API tokens expire after the period you set (max 30 days). Create a new token when the current one expires. - Rate limiting: MCP requests are throttled to 100 requests per minute per token. Exceeding this returns a 429 (Too Many Requests) response. - Brute-force protection: Repeated unauthenticated requests from the same IP address will be throttled. - Limited write access: The only tools that change anything are update_document_content (which edits document content, gated by the editable state and your update permission) and send_feedback (which does nothing beyond emailing your feedback to the AuditBadger team). Nothing else can be created, modified, or deleted through MCP. Troubleshooting - "Unauthorized" or connection refused: verify your API token is correct and has not expired. Check that API access is enabled for your account. - Configured before the transport change: older setups pointed at https://YOUR-SUBDOMAIN.auditbadger.com/mcp/sse with the SSE transport. That endpoint no longer exists — re-add the server with the Streamable HTTP transport and the /mcp URL as shown above. - Empty results: make sure you have compliance projects set up in AuditBadger. The MCP tools return data from your account — if there are no projects, controls, or documents, the results will be empty. - Search returns "not available": Global Search needs to be enabled in Account Settings. Ask an administrator to turn it on. - Token expired: create a new API token from your Profile page and update your MCP client configuration. - "Too many requests" (429): you've hit the rate limit. Wait a minute and try again, or reduce the frequency of requests. - Codex does not show AuditBadger tools: run codex mcp list and codex mcp get auditbadger --json, confirm AUDITBADGER_API_TOKEN is set in the environment that launches Codex, then start a new Codex session or restart the IDE extension. In project-scoped configs, also confirm the project is trusted. - Claude Desktop not connecting: make sure you're using the mcp-remote bridge — Claude Desktop's config file does not support remote servers directly, and the Connectors UI only works with OAuth-based servers. - Cursor not picking up changes: restart Cursor after editing .cursor/mcp.json. Check that your environment variable is set in the shell that launched Cursor.

FleetDM Integration User Guide

Overview AuditBadger connects to FleetDM once at the account level, then uses Fleet host inventory to maintain assets, device assignments, and endpoint compliance evidence. The integration is designed to avoid duplicate inventory work: - Fleet devices are selected by default during the first import review. - An exact serial-number match links the Fleet host to the existing AuditBadger asset instead of creating another asset. - A Fleet owner email that exactly matches an active AuditBadger user can manage the Fleet-owned checkout automatically. - Devices that cannot be matched are shown before import and reported in evidence after import. - Devices left outside the import selection are treated as a coverage gap by default. AuditBadger reads Fleet data but never locks, wipes, enrolls, unenrolls, or otherwise changes a device in Fleet. It also does not retrieve disk recovery keys. Before You Start You need: - AuditBadger account-admin access. - The HTTPS base URL of your Fleet server. - A Fleet API-only user token with a read-only role that can read hosts, host counts, device mappings, Fleet configuration, labels, and policies. - AuditBadger users with work email addresses matching the owner mappings used in Fleet. Use a dedicated API-only Fleet user for unattended collection. Keep its access read-only and revoke the user in Fleet if the integration should no longer connect. Connect FleetDM 1. In AuditBadger, open Settings > Integrations. 2. Open FleetDM. 3. Enter the Fleet server URL, including https://. 4. Enter the API-only user token. 5. Click Connect FleetDM. AuditBadger validates the token and confirms that hosts are readable. The integration page shows the Fleet organization, server, license tier when available, API user, and host count. If AuditBadger reports that the token belongs to a regular Fleet user, replace it with a dedicated API-only user token so scheduled collection is not tied to an interactive employee account. Review And Import Devices After the connection is valid, open Review Devices on the FleetDM integration page. Device import has its own screen so the complete Fleet inventory and every automatic decision can be reviewed together. The summary shows: - Fleet devices: every host visible to the integration token. - Existing assets linked: hosts that will update an existing AuditBadger asset. - New assets: hosts that will create an asset. - Needs attention: hosts with an ownership gap or an asset-matching conflict. Asset Matching AuditBadger matches each Fleet host in this order: 1. The Fleet host ID stored on a previously synced asset. 2. An exact hardware serial-number match. 3. The Fleet host UUID stored on a previously synced asset. For example, if Fleet reports serial P409W6WGWR and one asset in the same AuditBadger account already has serial P409W6WGWR, the importer shows that it will link to that asset. It does not propose a second asset. AuditBadger does not auto-link when the serial is ambiguous or the asset is already associated with a different Fleet host. The importer disables that host and asks the admin to resolve the asset data first. Matching is always limited to the current AuditBadger account. A serial in another customer account can never be linked. Owner Matching AuditBadger ranks Fleet device-mapping emails by source, then uses the highest-ranked candidate that exactly matches an active AuditBadger user. Email comparison is case-insensitive. The importer explains one of these outcomes for every host: - The owner matched an active AuditBadger user. - Fleet supplied an email, but no active AuditBadger user has that email. - Fleet supplied multiple possible owners. - Fleet did not supply a usable owner email. No fuzzy name matching is performed. Exact email matching avoids assigning a company device to the wrong person. Choose The Import Scope All non-conflicting devices are selected the first time the importer is opened. Usually the admin only needs to review the proposed links, optionally map Fleet platforms to asset categories, and click Save And Sync. You can deselect a device, but this creates an intentional Fleet coverage gap. The device inventory verifier fails by default while any Fleet device remains outside the AuditBadger import selection. Map Asset Categories For each Fleet platform, choose an existing AuditBadger asset category or enter a new category name. Category mapping applies only when an imported asset does not already have a category. Existing manual categories are preserved. What Sync Changes In AuditBadger For selected devices, a sync can: - Create missing assets. - Add Fleet metadata to safely matched existing assets. - Fill blank make, model, serial, or category values without overwriting existing manual values. - Create, refresh, return, or reassign Fleet-managed checkouts when the device owner matches an active AuditBadger user. - Mark previously synced Fleet assets as missing when their host disappears from the selected Fleet data. Manual checkouts remain authoritative. If a manual checkout conflicts with Fleet ownership, AuditBadger records a conflict and does not overwrite the manual assignment. Understand Warnings And Failed Checks The FleetDM integration and its device inventory evidence distinguish several conditions: Not Imported Fleet currently exposes more devices than the AuditBadger import selection contains. The complete-coverage verification rule fails by default until the devices are selected or the rule is explicitly relaxed. No Active AuditBadger Owner A Fleet device could not be matched to an active AuditBadger user. Selected devices reduce the owner-mapping percentage and can fail the configured threshold. Unselected devices with the same problem also produce an explicit verifier warning so they do not disappear outside the evidence scope. Ambiguous Owner Fleet returned multiple equally strong owner mappings. AuditBadger does not guess. Review the device mapping in Fleet, then sync again. Sync Conflict The same serial is associated with conflicting Fleet metadata, or a manual checkout disagrees with Fleet ownership. AuditBadger preserves the existing record and reports the conflict for review. Stale Device The device has not checked in within the configured number of days. The default device-inventory verification threshold is 30 days. Evidence Sources FleetDM can provide four automated evidence sources: - Endpoint Device Inventory: import coverage, active AuditBadger owner matching, Fleet status, staleness, and sync conflicts. - MDM Enrollment Status: Fleet MDM configuration and per-device enrollment posture. - Endpoint Disk Encryption: FileVault, BitLocker, or LUKS posture without recovery keys. - Screen Lock Policy Compliance: pass/fail results for the Fleet policies selected as screen-lock evidence. Use Install Evidence on the integration page to attach the appropriate sources to compliance controls. Screen-lock evidence remains unavailable until at least one Fleet policy is selected. Troubleshooting An Existing Asset Is Shown As New Compare the Fleet hardware serial with the AuditBadger asset serial. They must be an exact match. Also confirm the asset belongs to the same AuditBadger account and is not already linked to a different Fleet host. A Device Has An Email But No Owner Match Confirm an active AuditBadger user has exactly that email address. Deactivated, not-yet-active, terminated, or partner-managed users are not valid automatic owners. A Device Is Missing From AuditBadger Open Review Devices and confirm the host is selected. If it is visible but unselected, select it and click Save And Sync. If it is not visible, verify that the Fleet API-only user can read that host. The Importer Cannot Load Hosts Validate the integration connection. Confirm the Fleet URL is reachable, the token is valid, and the API-only user has read access to hosts and device mappings. A Manual Checkout Was Not Replaced This is intentional. AuditBadger never overwrites a manual checkout with Fleet ownership. Resolve the manual checkout or the Fleet mapping, then sync again. Disconnect FleetDM Disconnecting stops Fleet sync and evidence collection. Existing assets, checkouts, and collected evidence are retained. Revoke or delete the API-only user in Fleet if its token should no longer be usable. For product and implementation decisions, see prd_fleetdm-integration.md.

DigitalOcean Setup Guide

How to connect a DigitalOcean team to AuditBadger with a custom-scoped, read-only personal access token. Takes about 5 minutes. 1. Create the personal access token 1. In the DigitalOcean control panel, open API → Tokens. 2. Click Generate New Token and name it AuditBadger Compliance Read-Only. 3. Pick the longest expiration your policy allows (or no expiration if available) and note the date — you will enter it in AuditBadger. 4. Under scopes, choose Custom Scopes — do not use the Read Only or Full Access presets. 5. In the scope picker, search for each entry below and tick only its read checkbox. Leave every create, update, delete, and admin checkbox unticked: - account:read - project:read - regions:read - tag:read - droplet:read - image:read - snapshot:read - block_storage:read - block_storage_snapshot:read - firewall:read - vpc:read - vpc_peering:read - reserved_ip:read - load_balancer:read - certificate:read - domain:read - ssh_key:read - uptime:read - actions:read - database:read - kubernetes:read - cdn:read 6. Click Generate Token. 7. Copy the token immediately — DigitalOcean shows it only once. Tick nothing else. In particular never grant api:read, api:write, any write scope, database:view_credentials, kubernetes:access_cluster, app:access_console, security:read, or Spaces key scopes. AuditBadger does not need them, and its API client is hard-limited to an allowlist of GET endpoints, so it will refuse to use them. 2. Connect in AuditBadger 1. Go to Account Settings → Integrations → DigitalOcean (the tab appears when the feature flag is enabled for your account). 2. Paste the token and, if it expires, enter the expiration date so AuditBadger can remind you before collection stops. 3. Save. AuditBadger validates the connection in the background and discovers the team identity via GET /v2/account. 4. Once connected, install evidence sources on your compliance controls (individually from a control, or in bulk via "Install evidence sources"). Token rotation 1. Generate a new custom-scoped token in DigitalOcean with the same scopes. 2. On the integration page, open Configuration, paste the new token, update the expiration date, and save. Evidence sources and collected evidence are kept. 3. After AuditBadger re-validates, delete the old token in DigitalOcean. Troubleshooting - "Permission denied — the token is missing a required scope" - the token was created without one of the scopes above. Generate a new token with the full checklist; scopes cannot be edited after creation. - "Invalid or expired personal access token" - the token was revoked or expired. Generate and paste a new one. - Token expiring soon warning - generate a new token and update the configuration before the expiry date; collection stops when the token expires. - A domain/uptime source collects nothing - the team hosts no DNS zones or uptime checks on DigitalOcean; those sources only produce evidence for resources that exist.

AWS Integration Control Coverage Guide

AuditBadger Compliance Platform This guide explains how AuditBadger AWS evidence sources support SOC 2 and ISO 27001 control assessments and documents the default auto-verification rules. For connection setup, security, and IAM permissions, see the AWS Integration User Guide. SOC 2 Control Coverage The AWS integration provides evidence for the following SOC 2 (2017) Trust Services Criteria: These mappings identify evidence that can support a control assessment. A collected configuration or finding does not, by itself, prove that the full organizational control is implemented or operating effectively. CC6 - Logical and Physical Access Controls CC6.1 - Logical Access Security The entity implements logical access security software, infrastructure, and architectures to protect information assets - IAM Password Policy - Password complexity requirements are enforced - IAM MFA Status - Multi-factor authentication is enabled - IAM Access Keys - Access credentials are properly managed - S3 Encryption - Data at rest is encrypted - S3 Public Access Block - Data is not publicly exposed - RDS Encryption - Databases are encrypted - EBS Volume Encryption - Storage volumes are encrypted - KMS Key Rotation - Encryption keys are properly rotated CC6.2 - User Registration and Authorization Prior to issuing system credentials and granting access, the entity registers and authorizes new users - IAM MFA Status - Complete inventory of IAM users with access details - IAM Access Keys - Access key creation and authorization records CC6.3 - Removal of Access Rights The entity removes credentials and disables system access when no longer required - CloudTrail Events - Access revocation events are logged - IAM Access Keys - Inactive or unused access keys identified CC6.5 - Disposal of Data The entity disposes of data, software, and equipment to prevent unauthorized access - S3 Encryption - Encryption configuration provides supporting data-protection context; this collector does not evaluate object lifecycle or deletion rules - RDS Encryption - Encryption configuration provides supporting data-protection context; this collector does not evaluate database deletion procedures CC6.6 - Logical Access Security Measures The entity implements controls to prevent or detect and act upon unauthorized logical access - Security Groups - Firewall rules restrict access appropriately - Network ACLs - Network-level access controls are in place - VPC Flow Logs - Flow-log coverage is verified across VPCs - GuardDuty Status - Threat detection is active - GuardDuty Findings - Security threats are identified and tracked CC6.7 - Data Transmission Controls The entity restricts transmission and movement of data - S3 Encryption - Default encryption protects object data at rest - RDS Encryption - Storage encryption protects database data at rest CC7 - System Operations CC7.1 - Security Monitoring The entity monitors system components for anomalies and security events - GuardDuty Status - Threat detection service is active - Security Hub Status - Security monitoring is consolidated - CloudWatch Alarms - Alerts are configured for security events CC7.2 - Security Event Logging The entity identifies and logs security events - CloudTrail Configuration - Audit logging is properly configured - CloudTrail Events - Security events are recorded - VPC Flow Logs - Network flow-logging coverage is verified CC7.3 - Security Incident Response The entity evaluates security events and responds to identified incidents - GuardDuty Findings - Threats are detected and tracked - CloudWatch Alarms - Incident alerts are configured CC7.4 - Security Alerting The entity responds to identified security incidents - CloudWatch Alarms - Alarm states and notification actions provide monitoring evidence CC8 - Change Management CC8.1 - Change Management The entity authorizes, documents, and controls infrastructure changes - CloudTrail Events - Infrastructure changes are logged - AWS Config Status - Configuration changes are tracked A1 - Availability A1.1 - System Availability The entity maintains, monitors, and evaluates current processing capacity - Backup Jobs - Data can be recovered - RDS Snapshots - Database backups are maintained - CloudWatch Alarms - Availability monitoring is active A1.2 - Recovery Procedures The entity's recovery procedures support system recovery in accordance with recovery objectives - Backup Jobs - Backup procedures are executed successfully - RDS Snapshots - Point-in-time recovery is available ISO 27001:2022 Control Coverage The AWS integration provides evidence for the following ISO 27001:2022 Annex A controls: A.5 - Organizational Controls A.5.15 - Access Control Rules to control physical and logical access to information and other associated assets shall be established and implemented - IAM Password Policy - Password policies enforce access security - IAM MFA Status - Strong authentication is required - IAM Access Keys - Access credentials are managed - Security Groups - Network access is controlled A.5.16 - Identity Management The full life cycle of identities shall be managed - IAM MFA Status - Complete inventory of identities - IAM Access Keys - Access key lifecycle management A.5.17 - Authentication Information Allocation and management of authentication information shall be controlled - IAM Password Policy - Authentication requirements are enforced - IAM MFA Status - MFA is properly configured - IAM Access Keys - Credentials are properly managed A.5.18 - Access Rights Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed - IAM Access Keys - Access key usage is reviewed - CloudTrail Events - Access changes are logged A.5.23 - Cloud Services Security Processes for acquisition, use, management and exit from cloud services shall be established - GuardDuty Status - Cloud threat detection is active - Security Hub Status - Cloud security posture is monitored - CloudTrail Configuration - Cloud activity is logged A.8 - Technological Controls A.8.1 - User Endpoint Devices Information stored on, processed by or accessible via user endpoint devices shall be protected - EBS Volume Encryption - Storage attached to instances is encrypted A.8.3 - Information Access Restriction Access to information and other associated assets shall be restricted - S3 Public Access Block - Data is not publicly accessible - Security Groups - Network access is restricted - Network ACLs - Network-level access controls exist A.8.9 - Configuration Management Configurations, including security configurations, shall be established, documented, implemented, monitored and reviewed - AWS Config Status - Configuration changes are tracked - Security Groups - Security configurations are documented A.8.10 - Information Deletion Information stored shall be deleted when no longer required - S3 Encryption - Encryption configuration provides supporting data-protection context; this collector does not evaluate lifecycle or deletion policies A.8.11 - Data Masking Data masking shall be used in accordance with the organization's topic-specific policy - RDS Encryption - Encryption configuration provides supporting protection context; this collector does not test application-level data masking A.8.12 - Data Leakage Prevention Data leakage prevention measures shall be applied - S3 Public Access Block - Public exposure is prevented - GuardDuty Findings - Data exfiltration attempts are detected - VPC Flow Logs - Flow-log coverage and destination configuration are checked A.8.13 - Information Backup Backup copies of information, software and systems shall be maintained and regularly tested - Backup Jobs - Backups are executed regularly - RDS Snapshots - Database backups are maintained A.8.14 - Redundancy Information processing facilities shall be implemented with sufficient redundancy to meet availability requirements - RDS Encryption - Multi-AZ deployment status - Backup Jobs - Backup plan, vault, and recent job coverage A.8.15 - Logging Logs that record activities, exceptions, faults and other relevant events shall be produced, stored, protected and analysed - CloudTrail Configuration - API activity is logged - VPC Flow Logs - Network activity is logged - CloudWatch Alarms - Alarm configuration, state, and notification actions are inventoried A.8.16 - Monitoring Activities Networks, systems and applications shall be monitored for anomalous behaviour - GuardDuty Status - Threat monitoring is active - GuardDuty Findings - Anomalies are detected and tracked - CloudWatch Alarms - System monitoring is configured - Security Hub Status - Security posture is monitored A.8.20 - Networks Security Networks and network devices shall be secured, managed and controlled - Security Groups - Network security rules are configured - Network ACLs - Network access controls are in place - VPC Flow Logs - Network flow-logging coverage is verified A.8.21 - Security of Network Services Security mechanisms, service levels and service requirements of network services shall be identified, implemented and monitored - Security Groups - Network service exposure and risky inbound rules are reviewed - Network ACLs - Subnet-level traffic filtering and segmentation are reviewed A.8.24 - Use of Cryptography Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented - S3 Encryption - Object storage is encrypted - RDS Encryption - Databases are encrypted - EBS Volume Encryption - Block storage is encrypted - KMS Key Rotation - Encryption keys are rotated A.8.32 - Change Management Changes to information processing facilities and information systems shall be subject to change management procedures - CloudTrail Events - Recent management and write events provide change activity evidence - AWS Config Status - Recorder, delivery channel, and configuration-rule status are checked Verification Rules Auto-verified evidence sources use the following defaults. Accounts can customize supported thresholds when configuring an evidence source. IAM Password Policy - Minimum password length: 14 characters - Require uppercase letters: Yes - Require lowercase letters: Yes - Require numbers: Yes - Require symbols: Yes - Maximum password age: 90 days - Password reuse prevention: 24 passwords IAM MFA Status - Console users with MFA: 100% - Root account has MFA: Required IAM Access Keys - Maximum key age: 90 days - Active keys used within the last 90 days: Required - Multiple active keys per user: Not allowed CloudTrail - CloudTrail enabled: Required - Multi-region trail: Required - Log file validation: Required - Encryption enabled: Required S3 Security - Default bucket encryption: Required - Minimum encryption algorithm: AES-256 or AWS KMS - Account-level and bucket-level public access blocks: Required RDS Encryption - All instances encrypted: Required RDS Snapshots - Snapshot coverage for RDS instances: Required - Maximum age of latest snapshot: 7 days EBS and KMS - All EBS volumes encrypted: Required - Default EBS encryption enabled: Required - Automatic rotation for eligible customer-managed KMS keys: Required - Maximum key age without rotation: 365 days Network Security - No open SSH (0.0.0.0/0:22): Required - No open RDP (0.0.0.0/0:3389): Required - No unrestricted all-traffic ingress: Required - Network ACLs must not allow unrestricted inbound traffic: Required - VPC Flow Logs enabled: Required Monitoring, Security Services, and Configuration - CloudWatch alarms, security-relevant alarms, and notification actions: Required - GuardDuty enabled in at least one checked region: Required; partial regional coverage produces a warning - Maximum high-severity GuardDuty findings: 0 - Security Hub enabled in at least one checked region: Required; partial regional coverage produces a warning - At least one Security Hub standard enabled: Required - Maximum critical Security Hub findings: 0 - AWS Config enabled in at least one checked region: Required; partial regional coverage produces a warning - AWS Config recorder active in all enabled regions: Required - AWS Config rule findings: Up to 10 non-compliant rules produce a warning; more than 10 fail verification Backup Jobs - AWS Backup plans and a recent successful backup: Required - Maximum time since successful backup: 7 days Summary: Control Coverage Matrix SOC 2 Controls by Evidence Source IAM Password Policy - CC6.1: Yes IAM MFA Status - CC6.1: Yes - CC6.2: Yes IAM Access Keys - CC6.1: Yes - CC6.2: Yes - CC6.3: Yes CloudTrail Config - CC7.2: Yes CloudTrail Events - CC6.3: Yes - CC7.2: Yes - CC8.1: Yes CloudWatch Alarms - CC7.1: Yes - CC7.3: Yes - CC7.4: Yes - A1.1: Yes VPC Flow Logs - CC6.6: Yes - CC7.2: Yes GuardDuty Status - CC6.6: Yes - CC7.1: Yes GuardDuty Findings - CC6.6: Yes - CC7.3: Yes Security Hub - CC7.1: Yes AWS Config - CC8.1: Yes Security Groups - CC6.6: Yes Network ACLs - CC6.6: Yes S3 Encryption - CC6.1: Yes - CC6.5: Yes - CC6.7: Yes S3 Public Access - CC6.1: Yes RDS Encryption - CC6.1: Yes - CC6.5: Yes - CC6.7: Yes EBS Encryption - CC6.1: Yes KMS Key Rotation - CC6.1: Yes Backup Jobs - A1.1: Yes - A1.2: Yes RDS Snapshots - A1.1: Yes - A1.2: Yes ISO 27001 Controls by Evidence Source IAM Password Policy - A.5.15: Yes - A.5.17: Yes IAM MFA Status - A.5.15: Yes - A.5.16: Yes - A.5.17: Yes IAM Access Keys - A.5.15: Yes - A.5.16: Yes - A.5.17: Yes - A.5.18: Yes CloudTrail Config - A.5.23: Yes - A.8.15: Yes CloudTrail Events - A.5.18: Yes - A.8.32: Yes CloudWatch Alarms - A.8.15: Yes - A.8.16: Yes VPC Flow Logs - A.8.12: Yes - A.8.15: Yes - A.8.20: Yes GuardDuty Status - A.5.23: Yes - A.8.16: Yes GuardDuty Findings - A.8.12: Yes - A.8.16: Yes Security Hub - A.5.23: Yes - A.8.16: Yes AWS Config - A.8.9: Yes - A.8.32: Yes Security Groups - A.5.15: Yes - A.8.3: Yes - A.8.9: Yes - A.8.20: Yes - A.8.21: Yes Network ACLs - A.8.3: Yes - A.8.20: Yes - A.8.21: Yes S3 Encryption - A.8.10: Yes - A.8.24: Yes S3 Public Access - A.8.3: Yes - A.8.9: Yes - A.8.12: Yes RDS Encryption - A.8.11: Yes - A.8.14: Yes - A.8.24: Yes EBS Encryption - A.8.1: Yes - A.8.24: Yes KMS Key Rotation - A.8.24: Yes Backup Jobs - A.8.13: Yes - A.8.14: Yes RDS Snapshots - A.8.13: Yes Related Documentation - AWS Integration User Guide - AWS Setup Guide Last updated: July 2026

AuditBadger AWS Integration Setup Guide

Table of Contents 1. Overview 2. Prerequisites 3. Quick Start (CloudFormation) 4. Manual Setup 5. Verifying the Connection 6. Enabling Evidence Sources 7. Troubleshooting 8. Security & Permissions Overview AuditBadger's AWS integration enables automated evidence collection for SOC 2 and ISO 27001 compliance. Once connected, AuditBadger can: - Collect IAM password policies and MFA status - Monitor CloudTrail audit logging configuration - Check S3 encryption and public access settings - Verify GuardDuty threat detection status - Review security group configurations - Track RDS encryption and backups - Monitor KMS key rotation - And more... How It Works 1. You create a read-only IAM role in your AWS account 2. AuditBadger assumes this role to collect compliance evidence 3. Evidence is collected on a compliance-focused schedule (weekly or monthly) 4. Sources with auto-verification enabled are checked against their configured compliance rules 5. Results are linked to your SOC 2/ISO 27001 controls Security Model - Read-only access: AuditBadger cannot modify your AWS resources - Cross-account role assumption: We use AWS STS to securely access your account - External ID protection: Prevents confused deputy attacks - Time-limited credentials: Sessions expire after 1 hour - Auditable sessions: AWS API activity is attributable to the assumed AuditBadger role session where AWS records the relevant CloudTrail management events Prerequisites Before starting, ensure you have: - An AWS account with admin access (to create IAM roles) - Your AuditBadger account with an active subscription - Access to the AWS Console or AWS CLI Quick Start (CloudFormation) The fastest way to set up the integration is using CloudFormation. Step 1: Navigate to AWS Integration 1. Log in to AuditBadger 2. Go to Settings → Integrations → AWS 3. Click Connect AWS Account Step 2: Launch CloudFormation Stack 1. Click Launch CloudFormation Stack 2. This opens AWS CloudFormation with a pre-configured template 3. The required parameters (AuditBadger Account ID and External ID) are pre-filled 4. New stacks use the AuditBadgerAccountId parameter and default to the AuditBadgerComplianceRole role name Legacy compatibility: Older saved links or existing stacks may still show the HumadroidAccountId parameter or HumadroidComplianceRole role name. The template also retains HumadroidComplianceRole as its internal CloudFormation resource identifier. These names remain only to prevent existing installations from breaking. HumadroidAccountId is an alias for the same AuditBadger AWS account ID; it does not identify a separate service or account. Step 3: Create the Stack 1. Review the stack parameters 2. Scroll down to Capabilities 3. Check the box: "I acknowledge that AWS CloudFormation might create IAM resources" 4. Click Create stack Step 4: Copy Role ARN 1. Wait for the stack to reach CREATE_COMPLETE status (~1-2 minutes) 2. Go to the Outputs tab 3. Copy the RoleArn value Step 5: Complete Connection 1. Return to AuditBadger 2. Paste the Role ARN and choose the default AWS region 3. Click Connect AWS account 4. AuditBadger validates the connection in the background; use Test connection on the connected-account panel to run the health checks again Manual Setup If you prefer to create the IAM role manually: Step 1: Create IAM Role 1. Open the AWS Console 2. Navigate to IAM → Roles 3. Click Create role Step 2: Configure Trust Relationship 1. Select Another AWS account as the trusted entity type 2. Enter the AuditBadger AWS Account ID: [shown in AuditBadger setup page] 3. Check Require external ID 4. Enter the External ID: [shown in AuditBadger setup page] 5. Click Next Step 3: Attach Permissions Attach the following policies: 1. SecurityAudit (AWS managed policy) 2. A custom inline policy for additional permissions (see below) Step 4: Name the Role 1. Role name: Use the name shown in the AuditBadger setup page (default: AuditBadgerComplianceRole) 2. Add a description: "Read-only role for AuditBadger compliance evidence collection" 3. Click Create role Note: The role name is configurable per AuditBadger environment. If you're connecting the same AWS account to multiple AuditBadger environments (e.g., production and development), each environment will specify a different role name to avoid conflicts. Compatibility: Existing roles named HumadroidComplianceRole do not need to be renamed. AuditBadger validates the role ARN, trust policy, external ID, and permissions; the role name itself is not part of the application contract. Step 5: Copy Role ARN 1. Open the newly created role 2. Copy the Role ARN from the Summary section 3. Format: arn:aws:iam::YOUR_ACCOUNT_ID:role/ROLE_NAME Custom Inline Policy The CloudFormation template is the source of truth for the AuditBadgerCompliancePolicy inline policy. The older abbreviated S3, Backup, and AWS Config example previously shown here was not a complete replacement for the current template. For a manual installation: 1. Open the current auditbadger_compliance_role.yaml template 2. Copy the complete AuditBadgerCompliancePolicy policy document to the manually created role 3. Keep the AWS-managed SecurityAudit policy attached 4. Return to AuditBadger and run Test connection The template's S3 hostname retains legacy infrastructure naming, but the published filename, policy, default role name, and customer-facing setup all use AuditBadger. For the exact operations used by current evidence checks and the permissions inherited from SecurityAudit, see AWS Permissions Required. Verifying the Connection In AuditBadger After entering your Role ARN: 1. Click Test Connection 2. You should see: - ✅ Connection successful - AWS Account ID: Your 12-digit account ID - Account Alias: Your AWS account alias (if set) - Available Services: List of accessible AWS services Common Verification Results - All services accessible: The integration is ready; enable the desired evidence sources. - Some services inaccessible: The role has partial permissions; compare its policies with the current CloudFormation template. - Authentication failed: AuditBadger could not assume the role; verify the AuditBadger Account ID, External ID, and trust policy. - Role not found: Check that the Role ARN was copied exactly from the CloudFormation stack output or IAM role summary. Enabling Evidence Sources Once connected, enable evidence sources for your compliance controls: Step 1: Navigate to a Control 1. Go to Compliance → Projects → Select your SOC 2 or ISO 27001 project 2. Open a control (e.g., CC6.1 - Logical Access Security) Step 2: View Available Evidence Sources 1. Click the Evidence Sources tab 2. You'll see suggested AWS evidence sources for this control 3. Each source shows: - Name and description - Collection frequency - Auto-verify status Step 3: Enable Sources 1. Click Enable next to each desired source 2. Optionally customize: - Collection frequency (weekly or monthly) - Verification rules thresholds 3. Click Save Evidence Collection Schedule - Weekly: Used by active findings and backup-job evidence sources. - Monthly: Used by configuration, encryption, access, and audit-snapshot evidence sources. Collection scheduling is managed by AuditBadger. The evidence source shows its configured frequency in the application. Troubleshooting Error: "Cannot assume role" Cause: Trust relationship is incorrectly configured. Solution: 1. Open your IAM role in AWS Console 2. Go to Trust relationships tab 3. Verify the trust policy contains: {  "Principal": {"AWS": "arn:aws:iam::AUDITBADGER_ACCOUNT_ID:root"},  "Condition": {    "StringEquals": {"sts:ExternalId": "YOUR_EXTERNAL_ID"} } } 4. Ensure both Account ID and External ID match AuditBadger's values exactly Error: "Access Denied for iam:GetAccountPasswordPolicy" Cause: Missing IAM permissions. Solution: 1. Ensure the SecurityAudit policy is attached 2. Or add the specific permission to your inline policy Error: "Rate limit exceeded" Cause: Too many API requests in a short period. Solution: 1. AuditBadger automatically retries with exponential backoff 2. If persistent, reduce collection frequency 3. Contact support if issues continue Error: "Service unavailable" Cause: Temporary AWS service issue. Solution: 1. AuditBadger automatically retries these errors 2. Check AWS Service Health Dashboard 3. Collection will succeed on next attempt Connection works but evidence collection fails Possible causes: 1. Role permissions changed after initial connection 2. Evidence source needs permissions not in SecurityAudit 3. AWS service not enabled in your account (e.g., GuardDuty) Solution: 1. Re-test connection to verify permissions 2. Check the evidence source error message for specific permissions 3. Enable the AWS service if required Security & Permissions Permissions by Evidence Type The role uses read-only operations across IAM, CloudTrail, CloudWatch, AWS Config, GuardDuty, Security Hub, EC2, S3, RDS, KMS, AWS Backup, and STS. The complete, current operation list is maintained in AWS Permissions Required. That guide also explains why the role can show permissions inherited from AWS's managed SecurityAudit policy even when AuditBadger does not call those operations. Data Handling - Evidence data is encrypted at rest and in transit - Raw API responses are stored for audit purposes - Data retention follows your AuditBadger plan settings - You can delete evidence at any time Revoking Access To disconnect AuditBadger from your AWS account: 1. In AuditBadger: Settings → Integrations → AWS → Disconnect 2. In AWS: Delete the role shown in your integration settings, usually AuditBadgerComplianceRole. Older installations may still use HumadroidComplianceRole. Support If you need help with your AWS integration: - Documentation: AuditBadger AWS integration documentation - Related guide: AWS Integration User Guide