Find answers to common integration questions and issues. ### General Integration FAQs You need admin access to the specific tool to grant read-only permissions to Scrut for the integration. It depends on the tool you’re integrating with Scrut. For example, if you’re integrating an HRIS, Scrut fetches employee data. You can review the individual integration guides to know more about the data fetched for each integration. Scrut uses standards like SAML and OAuth 2.0 for secure authentication and authorization. - Your username and password are never shared with or stored by Scrut - Authentication is handled directly by the tool’s secure servers - Scrut only receives secure access tokens with limited, specific permissions - All data transmission is encrypted and follows industry security standards ### Cloud Providers FAQs Yes. Scrut automatically collects cloud-required evidence, such as IAM configurations, audit logs, resource settings, and activity reports, enabling continuous compliance monitoring and reducing manual evidence collection. Scans run automatically every 24 hours. You can also initiate on-demand rescans as needed for supported integrations. Scrut adheres to a least-privilege model, requesting only the minimum necessary permissions. Scrut requires read-only access to metadata, providing information about available configurations. For multiple subscriptions to the same cloud provider, you can integrate them separately. - For **AWS**, you can add multiple AWS accounts by clicking Configure, and then Add New in the Scrut interface. - For **GCP**, you can also add multiple accounts by clicking Configure and then Add New. - For **Azure**, you can configure the scope of the integration to specify which of your accounts you want included in the integration. Refer to the [integration guides](/docs/integrations-overview#4-cloud-providers) for step-by-step instructions. No, we never require access to your database or customer data. Scrut uses secure, encrypted connections (HTTPS, OAuth 2.0) for all cloud integrations. It follows least-privilege principles, requesting only the minimum permissions needed for compliance checks, and never stores sensitive credentials. Scrut supports multi-cloud environments by integrating with major providers (AWS, Azure, GCP), offering a unified view of your security and compliance posture. It continuously monitors configurations, access, and activity across all connected clouds for consistent policy enforcement and automated compliance checks. Admins receive an email notification about the integration failure, and cloud tests related to the failed integration appear grayed out in the portal. Scrut automatically detects and monitors resources across all regions within connected cloud accounts, ensuring consistent security policies and compliance checks globally, regardless of where the resources are hosted. Scrut fetches the data into the Tests and Compliance → Cloud modules. ### Version Control FAQs Scrut helps automate evidence collection for compliance audits by monitoring repository permissions, tracking changes to protected branches, validating security settings like MFA, and ensuring review workflows are followed, reducing manual audit efforts. Integrating your version control tools helps automate these tasks. Scrut requires read-only access to repository metadata, including permissions, branch protection settings, commit history, pull requests, and configuration details. It does not access actual code content. Code review results are uploaded bi-monthly. Other tests run once every 24 hours. Scrut uses repository metadata to verify security best practices, enforce compliance requirements (e.g., MFA, protected branches, PR reviews), and automatically collect audit-relevant evidence. Yes, access can be scoped to specific repositories during the integration process, and only selected repositories will be monitored. Yes, multiple repositories can be included in the scope. Scrut only accesses metadata and does not read source code. All data is encrypted in transit and at rest, and access is governed by strict internal security controls. No, a separate service account is not mandatory. You can revoke access at any time by disconnecting the integration. Scrut does not track or access your code—it only collects metadata relevant to security and compliance verification. Scrut collects metadata such as branch protection settings, user roles, repository visibility, MFA status, pull request reviews, and commit history to protected branches. No, Scrut runs passively and does not interfere with your development workflows, code deployment, or CI/CD processes. Yes, you can integrate multiple version control platforms simultaneously. No. Scrut does not analyze code quality; it focuses solely on compliance-related tracking and security configuration monitoring. Scrut monitors monorepos the same way as regular repos, focusing on repository-level settings and metadata rather than individual code modules. Scrut should be integrated with production environments, as these are most relevant for compliance audits and data protection. Auto-detecting the default branch requires code read access to your repositories. Scrut integrations are designed to access only the metadata needed for compliance. The `scrut_branch_name` custom property gives Scrut the branch information it needs while keeping your codebase completely private. ### HRIS FAQs When both your HRIS and IdP are integrated, Scrut prioritizes the employee data in your **HRIS**. Here's a concise breakdown: - **HRIS is the primary source of truth:** If an employee exists in both HRIS and IdP, the employee data is taken exclusively from HRIS. - **IdP as a fallback:** Scrut uses IdP as the source of truth only if an employee exists solely in IdP and not in HRIS. - **HRIS dictates status:** Removal from HRIS triggers offboarding in Scrut, even if the employee still exists in IdP. Similarly, if an employee previously only in IdP is later added to HRIS, the HRIS data overrides any prior offboarding state. - **Conflict resolution:** In case of simultaneous syncs, HRIS data takes precedence over IDP data. In essence, HRIS is the primary source of truth, with IdP serving as a secondary source only when employees don't exist in the HRIS system. HRIS integration helps automate access reviews and identity verification by syncing real-time employee data such as employment status and role assignments. This ensures that only active employees have access to critical systems and generates audit-ready reports that provide verifiable evidence for compliance checks. Scrut typically requires read access to user profiles (name, email, role, department) and employment status (active/inactive). Once every 24 hours. Full name and email, job title and department, employment status (active/inactive), and role and reporting structure (where available). Once integrated, all employees will sync to Scrut. You can mark service accounts as 'non-personnel' in Scrut to exclude them from the audit scope. When an employee's exit date is set in the HRIS, Scrut will pull that information. Once the exit date is reached, Scrut will initiate the offboarding process. Yes. When using both IDP and HRIS, Scrut considers HRIS the source of truth in the event of any conflicts. Scrut encrypts all data both in transit and at rest, follows least-privilege access controls, and complies with major security frameworks (like ISO 27001, SOC 2). Sensitive employee data is not stored or shared unnecessarily. Role changes detected via the HRIS sync are automatically logged and updated in the next sync. Yes. Departmental changes are captured during sync and updated in the employee profile. Scrut uses secure API connections (OAuth or token-based), data encryption, access logging, and role-based internal access controls. All integrations are regularly audited for security compliance. HRIS data powers automated user access reviews, offboarding validations, and employment audits. Yes, you typically need admin or API-level access to authorize the integration, configure permissions, and initiate data syncing with Scrut. You can move contractors to a separate group using the group functionality. Scrut does not automatically delete or mark employees as Offboarded when they are deactivated in the HRIS/IDP. Instead, when an employee is deleted or marked as inactive in your HRIS/IDP, Scrut captures this on the next sync and moves the employee automatically to the **Offboarding Needed** status, using their deactivation or exit date as the recorded exit date in Scrut. ### Identity Providers FAQs IdP integration enables SSO login for employees and imports employee data to Scrut. Scrut needs read permissions to access user information related to user groups, audit reports, and delegated administrator reports. Scrut collects user account details, group memberships, login activity, and security alerts to monitor access and ensure compliance. It requires permissions for admin audit logs, activity reports, and security alerts to perform automated checks. Currently, Scrut only supports primary email domains for mapping; multiple subdomains are not supported. Data is automatically updated every 24 hours. You can also manually trigger synchronization, as needed. All employees sync to Scrut after integration. To exclude service accounts from the audit scope, mark them as 'non-personnel' within Scrut. When an employee is deleted or suspended in your IdP, Scrut captures this on the next sync and moves the employee automatically to the **Offboarding Needed** status, using their deactivation or exit date as the recorded exit date in Scrut. You can integrate with an HRMS tool or manually import employee data. Add a user with IdP admin access to your Scrut account to complete the integration. You can remove this user from your Scrut account afterward. The connection uses industry-standard encryption protocols (HTTPS, OAuth 2.0) for secure data transmission. Scrut follows strict access controls and doesn't store credentials, maintaining a secure and compliant integration. Admins will receive an email notification about the failure. Yes, you can switch providers, but the originally connected IdP remains the source of truth for employee records. The new IdP will sync data regularly but won't override the primary source. Yes, you can connect multiple IdPs if needed. ### MDM (Mobile Device Management) FAQs Mobile Device Management (MDM) solutions are essential for ensuring compliance with data protection regulations. They provide visibility into device application usage and data access patterns, helping organizations maintain regulatory compliance. It is not mandatory, but an MDM tool helps in centrally monitoring endpoint security. Yes, you can connect multiple MDM tools in a single Scrut workspace. Employee Checklists support multi-select, so you can assign an employee more than one MDM tool to install. Once assigned, their device data appears separately for each tool under People → Employees → Technicals, and their specific action items appear under Employee Tasks based on exactly what they've been assigned.

Additional FAQs: Integrations

General Integration FAQs

Cloud Providers FAQs

Version Control FAQs

HRIS FAQs

Identity Providers FAQs

MDM (Mobile Device Management) FAQs