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 has a built-in MCP (Model Context Protocol) server. Connect Claude, ChatGPT, Claude Code, Codex, Cursor, or any MCP client that understands MCP authorization, and the assistant can read your compliance data and propose changes to it. The endpoint is: https://YOUR-SUBDOMAIN.auditbadger.com/agent/mcp Replace YOUR-SUBDOMAIN with the subdomain you log in on. That is all a client needs: it discovers the sign-in flow on its own, sends you to AuditBadger to choose what it may access, and returns with its own credential. There is no token to copy. The one rule worth knowing The assistant never writes. There is no tool on this server that changes a record. Every write is a proposal. The assistant assembles one or more intended changes into a change set, and that change set sits in a review queue until a person in your account opens it and decides — item by item, or approving the safe ones together. Only after a human decision does AuditBadger apply anything, and it applies it under that person's own permissions, against the exact record state the assistant said it had observed. That gives you three things an ordinary AI integration does not: - A gate. An assistant that misunderstands your policy produces a rejected proposal, not a wrong record. - A diff. The review screen shows what each item would change, the assistant's stated reason, and where it says the information came from. - An audit trail. Every applied change carries the agent channel, the connection that proposed it, the change set it came from, and the person who approved it. Filter the audit log by channel to separate assistant changes from what people did in the browser. There is one deliberate exception, off by default, described under Letting an agent approve its own safe changes. Before you start - API access must be enabled for your account. An administrator turns this on in Account Settings; without it every MCP request is rejected and the consent screen refuses. - You must be an active member. Connections are personal: the assistant acts under your name, with the access you chose, and only you (or an account administrator) can revoke it. Step 1: Connect your client The Connect your client panel under Profile → Connected agents carries the same instructions with your own subdomain already filled in. Every client below ends on the same AuditBadger consent screen, described in Step 2. Claude.ai** and Claude Desktop** 1. Open Settings → Connectors → Add custom connector. 2. Name it AuditBadger and paste the endpoint as the remote MCP server URL. Leave the client ID and secret fields empty. 3. Click Connect. The consent screen opens; after you allow access the connector shows as connected and its tools are available in new chats. Custom connectors exist only on the plans that offer them. If the option is missing, your plan or your organization administrator does not allow them. ChatGPT 1. Open Settings → Connectors and turn on Developer mode under Advanced if it is not on already. 2. Choose Create, name it AuditBadger, paste the endpoint as the MCP server URL, select OAuth, and create. The consent screen opens in your browser. Claude Code (CLI) claude mcp add auditbadger --transport http https://YOUR-SUBDOMAIN.auditbadger.com/agent/mcp Add --scope project to write .mcp.json at the project root and share the configuration with your team. It holds no secret: {  "mcpServers": {    "auditbadger": {      "type": "http",      "url": "https://YOUR-SUBDOMAIN.auditbadger.com/agent/mcp"   } } } In a session, run /mcp, pick auditbadger, and choose Authenticate. Your browser opens the consent screen. Each team member authenticates once on their own machine. Codex (CLI and IDE extension) codex mcp add auditbadger --url https://YOUR-SUBDOMAIN.auditbadger.com/agent/mcp codex mcp login auditbadger The second command opens your browser for the consent screen. Start a new session afterwards and confirm with codex mcp list. Cursor In .cursor/mcp.json (project) or ~/.cursor/mcp.json (global): {  "mcpServers": {    "auditbadger": {      "url": "https://YOUR-SUBDOMAIN.auditbadger.com/agent/mcp"   } } } In Cursor Settings → MCP the server shows Needs login. Click it and allow access on the consent screen. Any other MCP client - Transport: Streamable HTTP, stateless - Endpoint: https://YOUR-SUBDOMAIN.auditbadger.com/agent/mcp - Authorization: standard MCP authorization. An unauthenticated request receives 401 with a WWW-Authenticate challenge naming the protected-resource metadata; from there the client finds the authorization server, registers itself (dynamic registration or a client ID metadata document), and runs an authorization-code flow with PKCE. Refresh tokens are issued and rotate. - A client that does not understand MCP authorization can send a static agent token instead. See Static tokens. Most clients also let you control which tools are exposed to the model and which run without a prompt. Reviewing that list is worth the five minutes: this server is proposal-only, so an always-allow setting cannot cause a write on its own, but it can cause a queue full of proposals nobody asked for — and if you enabled agent approval, the safe ones among them get applied. Step 2: The consent screen The client sends you to a page on your own AuditBadger subdomain. You must be signed in there as yourself. The page names the client and where it will return you, and asks three things. Access per module. Access is set separately for each compliance module: Projects, Controls, Evidence, Documents, Risks, Checks, Vendors, Business continuity, Assets, ISMS workbook, and People. Each module gets one of three levels: - No access — the assistant cannot see the module at all. - Read — it can read that module and nothing else there. - Read and propose — it can read, and it can propose changes for review. Propose always includes read. If the client asked for specific access, that is preselected; otherwise every module starts at Read. Change it freely, and give the connection only the modules the job needs. The assistant can call whoami at any time to see exactly which scopes it holds, and whether it is connected through OAuth or a static token. Expiry. The default is 30 days and the maximum is 365. After that date the client must ask again, and you get this screen again. Pick the shortest window that fits how you work. Whether the agent may approve its own safe changes. Off unless you type the acknowledgement. See the next section before you do. Click Allow access and you return to the client. Click Deny and the client is told you declined; nothing is recorded. Connecting the same client again replaces the previous connection: the old one is revoked the moment the new one is granted, so there is never more than one live grant per client and person. Letting an agent approve its own safe changes By default you approve everything. There is an opt-in, per connection, that changes this: the agent may approve its own proposals, without you opening the review queue. It is deliberately narrow: - Only that connection's own proposals. One agent cannot clear another's queue. - Only reversible, bulk-safe changes. Judgment calls — risk assessments and treatment decisions, control implementation status, policy publication, evidence submission, vendor assurance reviews, unlinking infrastructure, check acceptances — are never eligible, whatever you agreed to. A set containing one is refused whole, so it comes back to you intact rather than half-decided. - Anything your own review would hide from you is not yours to delegate; that set is refused too. - The delegation lives on the connection and dies with it. Revoke it, let it expire, or reconnect the client, and the delegation is gone; there is nothing separate to remember to switch off. To enable it you type the sentence I understand the audit consequences on the consent screen, or later under Profile → Connected agents. That is the point of the exercise, and the consequence is real: your approval is recorded once, here, instead of once per change. Over MCP there is no record of what you asked the agent for, so the agent is the only witness that you asked for it. Every change it approves is still recorded against you by name, and carries the agent_delegated channel so an auditor can tell those apart from decisions you clicked. When the agent approves a set this way it must pass a user_statement: what you actually said when you asked for it. That sentence is recorded as the decision note on every item in the set, and it is the only evidence of your intent that this surface has — so it is worth reading back afterwards to check the agent recorded what you said rather than what it inferred. Turning it off asks for nothing. Withdrawing trust should never be harder than granting it. Managing connections Profile → Connected agents lists every connection you granted: the client, the access you chose, the expiry, when it was last used, and whether agent approval is on. Revoke from there. It takes effect immediately: the client's tokens stop working, and any change sets it proposed that nobody has decided yet are cancelled. Work a human already approved still completes. Account settings → Connected agents shows administrators every connection in the account, across all members, with the same revoke action. Administrators cannot connect on someone else's behalf; consent is always the member's own. A client can also disconnect itself. When it does, the connection is revoked here as well, on the agent channel, so the list always shows the truth. Connections are never deleted, only revoked, so the history of what each one did stays readable. Static tokens (advanced) Some runtimes cannot open a browser: a script, a CI job, a server-side agent framework. For those, a static agent token does what a connection does, with a secret you carry yourself. Find it under Profile → Connected agents, in the Static tokens (advanced) section at the bottom. 1. Give the token a name. Names are unique across your whole account, including revoked ones. 2. Add a description saying where it will be used. It is stored encrypted. 3. Set the expiry: 30 days by default, 365 at most. 4. Choose access per module, exactly as on the consent screen, then create the token. 5. Copy the secret immediately. It is shown once and cannot be recovered. Send it on every request: Authorization: Bearer YOUR-AGENT-TOKEN The token is only ever read from that header. Query parameters, cookies, and alternate headers are not consulted. Static tokens can be rotated (a replacement is issued and the old token revoked in one step, with a new name and expiry) and revoked, from the same page. To change a static token's scopes, rotate it. Agent approval can be enabled on a static token too, with the same acknowledgement. Client configuration for a static token is the OAuth configuration plus the header. Claude Code takes --header "Authorization: Bearer YOUR-AGENT-TOKEN"; Codex takes --bearer-token-env-var; Cursor takes a headers object with ${env:VAR}. Keep the secret in an environment variable, never in a committed file. Migrating from the old MCP endpoint The old endpoint is gone. https://YOUR-SUBDOMAIN.auditbadger.com/mcp, the one authenticated with a personal API token, was retired on 2026-08-22 and replaced by /agent/mcp. There is no compatibility window. A client that still calls it receives a JSON-RPC error (not a 404) explaining the retirement and naming /agent/mcp, so an assistant connected to the old URL can tell its user exactly what to do. Your REST API is unaffected. The v1 REST API at /api/v1 keeps its API tokens and its behaviour exactly as they were. To migrate: 1. Reconnect. Point the client at /agent/mcp with no header, and sign in through the consent screen. Your existing API token will not authenticate against /agent/mcp — it returns 401 agent_token_required, by design, because a human's credential should not be what an autonomous agent carries. 2. Update your prompts. The reads gained a lot of company: 68 now, against 13 before, covering risks, checks, business continuity, assets, the ISMS workbook, audit readiness, and the review pipeline itself. What changed for a prompt: - The old endpoint gave every read and every write its own tool. This one lists 21 tools and reaches everything else by key: read runs any of the 68 reads, and propose proposes any of the 59 operations. A prompt that names a tool should name the work instead, or the operation key — part 2 maps every old name to its key. - list_evidences is now list_evidence, reached through read. Calling the old name returns tool_renamed naming the replacement. - search is not on this server. Use the list reads with filters. send_feedback emails product feedback to the AuditBadger team directly, without review. - The six old write tools — create_vendor, update_vendor, update_control, update_document_content, record_vendor_assurance_review, and update_control_implementation — were kept for a while as aliases that proposed rather than wrote. They were removed on 2026-09-19 along with the per-operation tools. Their operation keys are vendor.create, vendor.update, control.update_metadata, document.update_content, vendor.record_assurance_review, and — for the last one, which was always two things — control.update_implementation_notes for notes or control.update_implementation for status. Send one or the other, never both. 3. Expect a different rhythm. A prompt that used to say "mark control A.8.1 implemented" and get a confirmation now gets a proposal receipt and a change set id. The assistant should read first, propose with the versions it read, then poll for the outcome — and tell you there is something waiting for review. 4. Tell your reviewers. Proposals arrive in a queue and notify by email. If nobody is watching that queue, the assistant's work quietly expires after 14 days. Historical changes stay put. Anything written through the old endpoint is still in your audit log under the mcp channel. Troubleshooting - The client never opens a sign-in page — check that the URL ends in /agent/mcp on your own subdomain, and that the client supports MCP authorization. If it does not, use a static token. - The consent screen says API access is off — an administrator enables it in Account Settings. - The consent screen sends you to sign in — you are signed in to a different AuditBadger account than the one in the URL, or not at all. Sign in on that subdomain and retry from the client. - 401 on every request — the connection expired or was revoked, API access was disabled, or your membership is no longer active. Reconnect from the client. The 401 is deliberately identical in all these cases. - invalid_grant on refresh — the connection behind the token has ended. Reconnect from the client. - 401 after migrating — you are still sending an API token. Remove the header and reconnect, or issue a static agent token. - Client points at /mcp — that endpoint no longer exists. Update the URL to /agent/mcp. - MCP error -32602: Invalid params on list_risks, list_vendors, or another read — the name is a read key, not a tool, and no arguments fix it. The assistant calls read with that key. See part 2. - 429 — wait for Retry-After. If it persists with light usage, you are probably sharing an egress address and hitting the per-IP ceiling. - Requests blocked entirely — an IP that presented 30 rejected bearers in 10 minutes is banned for 30 minutes. Fix the client first, then wait it out. - 503 with Retry-After: 60 — ingress is paused for maintenance. Retry in a minute. - The assistant says it changed something but nothing changed — it proposed. Open the review queue; it is waiting for you. - Proposals refused as stale — something else is editing the same records. Have the assistant read immediately before proposing. - A multi-item set refused as conflicting_items — one item writes a resource another item observed; item_position names the item to move to its own set and detail the shared resource. Two evidences for one control need separate sets; separate sets for one control stay approvable after one of them applies. - Uploads refused — check the type against the allowlist, then the size, then whether the connection has a propose scope for evidence or vendors. upload_active_content means a PDF carried script or actions; flatten it. upload_invalid carries a reason, next_action, and guidance; follow them — a fresh request_upload_url for every reason but completion_reserved, which asks for a replay of the original idempotency_key. - The file PUT fails — the url from request_upload_url is on AuditBadger's own host and needs no bearer. A 401 means the five-minute capability passed or the URL was altered: request a new one. A 422 names the mismatch (size_mismatch, checksum_mismatch, content_type_mismatch): declare the file you actually send. A 503 is the object store: PUT again. - complete_staged_upload says retryable: true, then upload_invalid on the retry — the retry used a new idempotency_key. Retry with the same key; the first call reserved the upload for it. Client status The OAuth flow was built against the MCP authorization specification and is exercised end to end in the test suite by the official MCP Ruby client's OAuth flow, from the bare server URL to a tool call. Confirmation by hand per hosted client is recorded here as it happens: - Claude.ai custom connector: to be verified - Claude Desktop custom connector: to be verified - Claude Code: to be verified - ChatGPT developer-mode connector: to be verified - Codex: to be verified - Cursor: to be verified Next: the tools and the review flow This page covered connecting. What the assistant can actually do — the tools, the proposal-and-review rhythm, and worked examples — is https://help.auditbadger.com/hc/auditbadger-help-center/articles/1788254081-mcp-server-tools-review-flow-and-limits . File attachments, rate and workload limits, error codes, and the lifecycle notifications are https://help.auditbadger.com/hc/auditbadger-help-center/articles/1790025903-mcp-server-files-limits-and-errors .

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

MCP Server — Tools, Review Flow, and Limits

This is the second part of the MCP server guide. Part 1 — issuing an agent token, scopes, delegation, and connecting each client — is here: https://help.auditbadger.com/hc/auditbadger-help-center/articles/1775898378-mcp-server-connect-ai-assistants-to-humadroid Part 3 — attaching files, rate and workload limits, error codes, and lifecycle notifications — is here: https://help.auditbadger.com/hc/auditbadger-help-center/articles/1790025903-mcp-server-files-limits-and-errors The tools The server lists 21 tools. That is deliberately small: a long tool list crowds out a model's attention, and some clients silently drop the tail of one. Most of what the server can do is not a tool of its own — 68 reads and 59 proposal operations sit behind two gateways, read and propose, which take the thing you want by key. The assistant fetches the schema for one key on request. You never need to memorise any of this. The assistant discovers it, and the server's instructions tell it how the pieces fit together. Here is the shape. Reads (68) Thirteen have a tool of their own, the ones nearly every session needs: whoami, describe_operations, describe_reads, list_available_operations, operation_companion, list_projects / get_project, list_controls / get_control, list_documents / get_document, and list_change_sets / get_change_set. Every other read runs through read, which takes the read's key and that read's own input: {"key": "list_risks", "input": {"limit": 50}} A key is not a tool. list_risks, list_vendors, list_risk_scoring_methods, and every other name in the catalogue below that is not one of the thirteen above exists only as a key for read. Calling one as a tool of its own never reaches AuditBadger's validation: the client shows its generic unknown-tool error — in most clients MCP error -32602: Invalid params, with Tool not found: <name> in the error's data, which some clients hide. That message is not a schema problem and no arguments fix it. The schema describe_reads returns for a key is the shape of read's input, not of a tool named after the key. describe_reads returns the version, description, input schema, and output schema for up to ten keys in one call. An assistant calls it before a key's first use, and again if a read call comes back invalid_request — that refusal names the field that broke the rule. Every read returns current state plus an observed version for each resource. Two reads legitimately return different observed versions for the same record: each fingerprints its own projection, answering "has what this read shows changed?", not "has the row changed?". Only the versions returned by the operation companion (the operation_companion tool, or the operation's paired read) are valid in a proposal — every read envelope says so in capability.operation_companion_required_for_mutation. Hand those back when proposing, and if the record moved in between, the proposal is refused as stale instead of overwriting someone's work. The catalogue, by key — the thirteen listed tools are in it too, and every other name is called through read: - Orientation: whoami, list_available_operations, describe_operations, describe_reads, operation_companion, get_project_posture - Projects and controls: list_projects / get_project (both report the framework and the setup facts; get_project with include: ["onboarding_questions"] adds the wizard questions and the answers that give the project its context, and include: ["posture"] embeds the posture aggregate), list_sections / get_section, list_controls / get_control (controls report their notes and whether notes and status are directly editable, so a register audit is one list call) - Audit readiness: get_audit_readiness (the verdict, the per-domain status, and what must close first), list_audit_readiness_gaps - Evidence: list_evidence / get_evidence, list_collection_sources / get_collection_source - Documents: list_documents / get_document, list_document_assignments - Risks: list_risks / get_risk, get_risk_assessment_context, list_treatment_actions / get_treatment_action - Checks: list_checks / get_check, list_check_acceptances / get_check_acceptance - Vendors: list_vendors / get_vendor (each vendor also reports its vendor type, the answers to that type's questions, its evidence checklist, any open "needs review" flags and the risks the type suggested), list_assurance_reviews / get_assurance_review - Business continuity: list_business_continuity_processes / get_business_continuity_process, and the same pair for plans and exercises - Assets: list_physical_assets / get_physical_asset, the same for digital and infrastructure, plus list_asset_relationships and list_asset_reference_data - ISMS workbook: get_isms_workbook, list_workbook_requirements / get_workbook_requirement, list_security_objectives / get_security_objective, list_management_reviews / get_management_review, and list_management_review_input_candidates - People: list_people / get_person, list_employment_types / get_employment_type - Reference vocabularies: list_data_classification_levels (documents access), list_risk_scoring_methods / get_risk_scoring_method (risks access) - Pipeline: list_users, list_change_sets / get_change_set, list_staged_uploads / get_staged_upload A readiness check is proposed, not run: an assistant that sees stale proposes readiness.run_create and you approve it. One check per project per day: a second proposal that day answers with the run you already have. vendor.update can give a vendor its type (vendor_type_key, or "" to remove it). Answering that type's questions is part of recording a review: vendor.record_assurance_review carries the answers (vendor_type_facts, a list of {key, value}) and decides each piece of evidence the type expects (checklist_decisions, a list of {requirement_key, state, note} where the state is auto, upload or not_applicable, and not_applicable needs the note that explains it). The review keeps what it was recorded with, and get_assurance_review returns that snapshot. Read the vendor first: the questions and requirement keys are your account's own vendor type, and anything else is refused with the valid keys named. document.mark_reviewed records that a published policy was re-read and still stands: it moves the next review date instead of republishing an unchanged copy. It only ever records "no changes" — if the policy needs rewriting, the assistant proposes document.create_version. Give it a next_review_date when the document has no review cadence of its own. Control reads report whether in-app AI implementation notes still await a person's approval, without returning the private notes. ISMS requirement reads report the same pending/approved state for AI-prefilled narratives; the requirement's ordinary reviewed state identifies the approving person and time. A manual edit after approval makes the text human-authored again. Proposing a change (59 operations) propose turns one registered operation into a one-item change set for review. It takes: - operation_key — which operation: control.create, risk.assess, document.publish, evidence.create, and so on. describe_operations with that key returns the schema for params, and list_available_operations says which of them this token may propose against a given record. - idempotency_key — reuse it to replay a submission safely rather than to make a second one - title — names the proposal, not the record - rationale — optional: what the assistant concluded and why - params — the operation's own fields - observed_versions — the versions operation_companion returned for the record about to change - source_refs — where the information came from, [] for internal-only work - compliance_project_id — required for a project-scoped operation and refused for an account-scoped one; describe_operations reports which each is {  "operation_key": "control.update_implementation_notes",  "idempotency_key": "b2e1…",  "title": "Refresh access-control notes after policy review",  "params": {"control_id": "…", "implementation_notes": "…"},  "observed_versions": {"…": "…"},  "source_refs": [],  "compliance_project_id": "…" } 43 of the 59 operations are bulk-safe: reversible bookkeeping a reviewer can approve together. The other 16 need explicit judgment and must be decided one at a time, because they are the moments where a person is asserting something to an auditor, or handing somebody authority over somebody else: - risk.assess, risk.update_treatment, risk.create_treatment_action - control.update_implementation - document.publish, document.mark_reviewed - evidence.submit - vendor.record_assurance_review - check_acceptance.create - asset.unlink_infrastructure - isms.requirement.mark_reviewed - isms.security_objective.create, isms.security_objective.update, isms.security_objective.record_review - isms.management_review.complete - people.person.set_manager Two of those go further. document.publish and isms.management_review.complete are the only operations that reach an action the server otherwise refuses outright, so neither is ever eligible for the per-token delegation described in part 1: a signed-in person confirms the item, whatever the token is allowed to approve. Lifecycle tools (3) - submit_change_set — propose several related changes as one set, with dependencies between items where one needs another to land first - cancel_change_set — withdraw a proposal the assistant no longer stands behind - approve_change_set — only usable when you have enabled the per-token delegation described in part 1 Upload tools (2) request_upload_url and complete_staged_upload. See Attaching files in part 3. Feedback (1) send_feedback — the one tool that acts immediately. It emails product feedback — a bug, a missing capability, a place the assistant got stuck — to the AuditBadger team. It needs no scope, goes through no review, and changes nothing in your account. What changed on 2026-09-19 Until that date the server listed 138 tools: one per read, one per operation named after it (risk_assess, control_create, and so on), and six aliases carried over from the retired /mcp endpoint (create_vendor, update_vendor, update_control, update_control_implementation, update_document_content, record_vendor_assurance_review). All of those are gone, and nothing the server can do went with them: the same 68 reads and the same 59 operations are there, reached by key through read and propose. Assistants pick this up by themselves, because a client reads the tool list again in every session. Only a saved prompt that names a removed tool needs your attention, and the fix is to name the operation instead of the tool: - control_create becomes propose with operation_key: "control.create". Every focused tool was named after its operation with the dots turned into underscores, so the key is recoverable from the old name; whoami also lists every operation the token may propose. - create_vendor is vendor.create, update_vendor is vendor.update, update_control is control.update_metadata, update_document_content is document.update_content, and record_vendor_assurance_review is vendor.record_assurance_review. - update_control_implementation was always two things: notes are control.update_implementation_notes, status is control.update_implementation, and the status one is a judgment call decided on its own. - A read without a tool is read with its key: {"key": "list_risks"}. list_evidences is the one old name with a shim — calling it answers with its replacement (read with key: "list_evidence") rather than a bare error. Any other removed name produces the client's ordinary "unknown tool" message — MCP error -32602: Invalid params in most clients — and an assistant that sees one finds propose and read in the list it has just read. An older copy of this guide, or a client that cached the old tool list, can still name a read as a tool; the name is the key, and read is the tool. A worked example Suppose you ask an assistant: "Our access-control policy has been in draft since the review. Check whether the control it covers is still marked unimplemented, and fix the notes." 1. It reads. list_documents finds the policy. get_control returns the control and its implementation notes. Then, because it intends to propose, the assistant calls operation_companion for control.update_implementation_notes on that control — the companion's observed_versions are the ones a proposal must carry. 2. It proposes. propose with operation_key: "control.update_implementation_notes" and: - idempotency_key: a fresh UUID - title: "Refresh access-control notes after policy review" - rationale: what it concluded and why - params: the new notes - observed_versions: the versions the operation companion returned - source_refs: a reference to the policy document it read - compliance_project_id: the project The receipt comes back with a change_set_id, state proposed, and a review_path. Nothing has changed yet. Note what it did not do: implementation status is control.update_implementation, an explicit-judgment operation. An assistant that decides a control is implemented is asserting a compliance fact, so that comes to you as its own decision even inside a bigger set. 3. You review. The change set appears in your review queue, and you get a notification. The item shows the before and after, the assistant's rationale, and the source it cites. You approve it, reject it with a note, or leave it — proposals expire on their own within 14 days by default. 4. It polls. get_change_set returns the state and, per item, an outcome code and a next_action telling the assistant what to do: await_review (nothing to do yet), await_apply (decided, queued), none (done, or permanently refused), repropose (read again and try once more — this is what a stale version gets), or retry. A set ends in applied, partially_applied, rejected, failed, cancelled, or expired. Per item, the application state is applied or one of failed_precondition, failed_validation, failed_infrastructure, skipped_dependency_rejected, skipped_dependency_failed. 5. The audit log records it. Account Settings, Security, Audit Logs. The entry carries the agent channel, the token, the change set, and you as the approver. A second example: onboarding a new employment type "We are taking on contractors. Create a contractor employment type, require the handbook of it, and move Ada onto it." read with key: "list_employment_types" shows the type does not exist, and list_documents — a listed tool — finds the published handbook. Then three proposals, in order: people.employment_type.create with the name, people.employment_type.link_documents naming the handbook, and people.person.set_employment_type naming Ada and the new type. There is no compliance_project_id — these are account-scoped. Approving the third one does what the settings screen does: Ada is asked to acknowledge every document her new employment type requires, and to sign every contract it carries, inside the same operation. The receipt tells you how many assignments that created. Withdrawing a requirement later, with people.employment_type.unlink_documents, does not take those obligations back — the operation says so in describe_operations, because cancelling what somebody already owes is a separate decision a person makes on the web. The assistant cannot invite Ada, change her role or email, set her joining or leaving date, deactivate her, or acknowledge a document on her behalf. Those are not operations at all — there is no key to propose them with.

Azure Integration User Guide

AuditBadger's Azure integration automatically collects compliance evidence from your Microsoft Azure infrastructure and Microsoft Entra (formerly Azure AD) directory. Once connected, it checks your tenant and subscriptions on a monthly schedule and gathers evidence that satisfies controls for SOC 2 and ISO 27001 frameworks. Key benefits - Automated evidence collection — no more manual screenshots or exports - Read-only access — AuditBadger never makes write API calls - Multi-subscription support — one service principal can grant access to many subscriptions in the same Entra tenant; rotate the secret in one place to update all of them - Auto-verification — every collected source is automatically checked against your compliance rules Security model - Read-only RBAC roles only (Reader, Key Vault Reader) - Microsoft Graph application permissions are admin-consented and read-only - Client secret is encrypted at rest using Rails Active Record Encryption - Tokens are never logged; only short-lived OAuth2 access tokens are minted on demand Evidence sources The Azure integration collects thirteen evidence types. Every source runs monthly by default and is auto-verified. Identity (Microsoft Entra): - Entra MFA Status — verifies MFA enrollment coverage across the tenant, MFA-enforcing conditional access policies, and admin MFA registration. Maps to SOC 2 CC6.1, CC6.6 and ISO 27001 A.5.15, A.5.17. - Entra Conditional Access Policies — inventories conditional access policies, their grant controls, and which apps and users they target. Maps to SOC 2 CC6.1, CC6.6 and ISO 27001 A.5.15, A.5.17. - Entra Privileged Role Assignments — inventories active assignments of Global Administrator and other directory roles. Maps to SOC 2 CC6.1 and ISO 27001 A.5.15. Logging and monitoring: - Activity Log Configuration — verifies subscription-level diagnostic settings export the Activity Log to Log Analytics, Storage, or Event Hub with the required retention and event categories. Maps to SOC 2 CC7.2, CC7.3 and ISO 27001 A.8.15, A.8.16. - Defender for Cloud Secure Score — collects the Defender for Cloud secure score and unresolved high-severity recommendations. Maps to SOC 2 CC7.1, CC7.2 and ISO 27001 A.8.16. - Monitor Alert Rules — inventories Azure Monitor metric alerts and activity-log alerts. Maps to SOC 2 CC7.1, CC7.2 and ISO 27001 A.8.16. Storage and encryption: - Storage Account Encryption — verifies encryption-at-rest, HTTPS-only enforcement, and minimum TLS on every Storage account. Maps to SOC 2 CC6.1, CC6.6, CC6.7 and ISO 27001 A.8.24. - Storage Account Public Access — audits public-blob and network-rule settings on every Storage account. Maps to SOC 2 CC6.1, CC6.6. - Managed Disk Encryption — verifies encryption-at-rest on every managed disk and reports the key source. Maps to SOC 2 CC6.1, CC6.7 and ISO 27001 A.8.24. - SQL Database Encryption (TDE) — verifies Transparent Data Encryption on every Azure SQL Database. Maps to SOC 2 CC6.1, CC6.7 and ISO 27001 A.8.24. - Key Vault Key Rotation — verifies key rotation policies and expiry on every key in every Key Vault. Maps to SOC 2 CC6.1, CC6.7 and ISO 27001 A.8.24. Network: - SQL Server Firewall Rules — audits SQL server firewall rules for 0.0.0.0/0 ingress and over-permissive ranges. Maps to SOC 2 CC6.1, CC6.6 and ISO 27001 A.8.20. - Network Security Groups — audits NSG rules for 0.0.0.0/0 ingress on RDP, SSH, and database ports and over-permissive outbound rules. Maps to SOC 2 CC6.6, CC6.7 and ISO 27001 A.8.20. Not collected yet: Backup jobs, and Privileged Identity Management eligible assignments (only active role assignments are read). Setup 1. Register a service principal In the Azure Portal: - Open Microsoft Entra ID → App registrations → New registration. Name it AuditBadger Compliance. - Open Certificates & secrets → New client secret. Copy the Value immediately — you'll only see it once. You can also use the bundled az CLI script (Setup → Show script) or the Bicep / ARM JSON templates for IaC-first teams. 2. Assign subscription RBAC roles On each subscription you want AuditBadger to monitor, grant the service principal these roles: - Reader - Key Vault Reader You can do this in Subscription → Access control (IAM) → Add role assignment, or with the provided Bicep/ARM templates. 3. Grant Microsoft Graph permissions In App registrations → Your app → API permissions, add these Microsoft Graph application permissions and click Grant admin consent: - Directory.Read.All - Policy.Read.All - UserAuthenticationMethod.Read.All - AuditLog.Read.All If your security team won't approve Directory.Read.All, you can disable Entra signal collection per integration in AuditBadger settings; you'll lose the three Entra sources (MFA Status, Conditional Access Policies, Privileged Role Assignments); subscription-level sources keep collecting. 4. Connect the subscription in AuditBadger Go to Settings → Integrations → Microsoft Azure → Connect Azure subscription. - If this is your first Azure integration, register the service principal first (Tenant ID, Application (client) ID, Client secret, optional display name). - Pick a subscription from the dropdown (AuditBadger auto-discovers subscriptions visible to the SP) or paste the Subscription ID directly. - Optionally set a label. AuditBadger validates the connection in the background and starts collecting evidence on the configured schedule (monthly by default). Multi-subscription customers If you have multiple subscriptions in the same Entra tenant, you can connect them all under a single service principal: - Register the SP once. - In Connect Azure subscription, choose Use existing service principal and pick a different subscription. When you rotate the SP secret in Azure, paste the new secret on the SP detail page in AuditBadger. Every connected subscription will be re-validated automatically. Rotating credentials Azure client secrets have a maximum lifetime of 24 months; many security teams rotate every 3–6 months. - Open the service principal in Settings → Integrations → Microsoft Azure → Service principals → [your SP]. - Generate a new secret in Azure (Certificates & secrets → New client secret). - Paste the new secret value in the Rotate client secret form and click Rotate. - AuditBadger invalidates cached tokens, re-validates every linked subscription in parallel, and shows live status for each. Disconnecting - Disconnect a subscription: removes the Integration::AzurePayload row. Evidence sources tied to that subscription stop collecting. Other subscriptions under the same SP are unaffected. - Delete a service principal: blocked while subscriptions reference it. Disconnect all subscriptions first. Troubleshooting - "Invalid client secret or tenant configuration" — check the Tenant ID and re-paste the secret. Secrets can also expire; verify it's still valid in Entra. - "Service principal lacks Reader on subscription X" — assign the Reader role on the subscription. Use the in-app Bicep/ARM template for one-shot fixes. - "Microsoft Graph permission 'UserAuthenticationMethod.Read.All' is missing" — open the app registration in Entra → API permissions → click Grant admin consent. The same message names whichever Graph permission is missing. - "Subscription not found in tenant" — the Subscription ID doesn't exist under the Entra tenant the SP belongs to. Re-pick from the dropdown. - Health check showing some services as degraded is normal if you haven't enabled Defender for Cloud or have no Key Vaults. The unhealthy services are skipped; the rest still collect evidence.