OpenDocket — hyperswitch

Compliance Risk Analysis

hyperswitch

https://github.com/juspay/hyperswitch
Scanned 2026-03-23 · OpenDocket V1 · Primary: Claude Sonnet · Review: Gemini 2.5 Flash

Important Limitations of This Report

This report is not legal advice and is not defensible in court. It provides directional guidance only. To obtain a defensible compliance assessment, engage a licensed attorney and certified auditor.

Scope limitations: Only public repository content was analyzed. Infrastructure configuration, deployment settings, operational policies, vendor contracts, and staff training are outside scope.

A true compliance audit would also review: vendor contracts and BAAs, staff training records, incident response procedures, physical security controls, and system audit logs — none of which are visible in source code.

Risk Assessment

This analysis identified 56 compliance patterns across GDPR, HIPAA, PCI-DSS, SOC2, SOX, TCPA. After independent verification by Gemini 2.5 Flash, 4 high-severity findings were confirmed and 52 were identified as possible false positives — likely pattern matches in documentation or configuration files rather than application source code. The 4 confirmed findings represent the primary areas requiring attention.

ELEVATED RISK

4 confirmed high-severity findings
45 total patterns identified · 52 flagged as possible false positives by independent review

What This Means If Unaddressed

Framework	Regulatory Body	Max Penalty	Enforcement Trend
GDPR (9 high)	EU DPAs	Up to EUR 20M or 4% turnover	Cross-border enforcement rising
TCPA (8 high)	FCC	$500-$1,500 per violation	Class action filings at record levels
SOX (7 high)	SEC / PCAOB	Criminal penalties, delisting	IT controls under increased scrutiny
SOC2 (7 high)	AICPA	Loss of enterprise contracts	Mandatory for enterprise SaaS sales
PCI-DSS (7 high)	PCI SSC	Fines $5K-$100K/month	v4.0 enforcement accelerating
HIPAA (7 high)	HHS / OCR	Fines up to $1.5M/year per category	Increasing enforcement, record penalties in 2024

Top Findings

High RiskGDPRGDPR-003connector-template/mod.rs:593 · Review: CONFIRMED

Implement a comprehensive right to erasure system that includes: (1) a user-facing mechanism for data subjects to submit deletion requests, (2) automated workflows to process these requests within the

High RiskPCI-DSSPCIDSS-004aws/hyperswitch_aws_setup.sh:167 · Review: CONFIRMED

Implement restrictive CIDR blocks instead of 0.0.0.0/0 to limit access to only necessary IP ranges. Create separate VPCs or subnets for the cardholder data environment with dedicated security groups t

High RiskSOC2SOC2-010.github/ISSUE_TEMPLATE/bug_report.yml:88 · Review: CONFIRMED

Create and document comprehensive security policies that demonstrate the organization's commitment to integrity and ethical values. This should include: (1) an acceptable use policy defining appropria

Gemini Verification Layer

How to read this: The confirmed count is your action list. The false positive count shows where the scanner found keyword patterns in documentation rather than application source code. Click any finding to see exactly what evidence was found and why Gemini made its determination.

4Confirmed

0Context dependent

52Possible false positives

0Additional risk

Primary: Claude Sonnet (Anthropic). Verification: Gemini 2.5 Flash (Google). Neither constitutes legal advice.

Recommended Actions

High

Integrate a robust data deletion workflow, distinct from the `hyperswitch_masking::ErasedMaskSerialize` mechanism observed in files like `connector-template/mod.rs` and `crates/common_utils/src/request.rs`, to permanently remove personal data across all systems upon a valid erasure request. Relying on masking instead of comprehensive deletion is a direct violation of GDPR Article 17, Right to Erasure.

GDPR · GDPR-003 · Confirmed

High

Update the `aws ec2 authorize-security-group-ingress` commands within `aws/hyperswitch_aws_setup.sh` (lines 53 and 62) to use restrictive `--cidr` blocks instead of implicitly open rules for ports 80 and 22. Additionally, confirm that the security group referenced by `$RDS_SG_ID` (line 167) only permits inbound traffic from authorized CDE components. This action directly supports PCI DSS Requirement 1 by enforcing granular network segmentation for the Cardholder Data Environment.

PCI-DSS · PCIDSS-004 · Confirmed

High

Create and document comprehensive security policies, including acceptable use, data classification, and access management policies, as required by SOC2-010. While `.github/ISSUE_TEMPLATE/bug_report.yml` and `.github/ISSUE_TEMPLATE/feature_request.yml` refer to 'Contributing Guidelines', these do not substitute for formal security policies, and their absence poses a high risk to demonstrating the organization's commitment to integrity and ethical values.

SOC2 · SOC2-010 · Confirmed

High

Update `.github/CODEOWNERS` for `crates/router/src/workflows/payment_method_status_update.rs`, `crates/router/src/workflows/attach_payout_account_workflow.rs`, and `crates/router/src/services/authorization.rs` to require review and approval from a separate, independent team or individual. Failure to establish distinct roles for developing and approving changes to financial transaction processing code violates SOX segregation of duties requirements and elevates the risk of financial misstatement.

SOX · SOX-005 · Confirmed

Risk Scorecard

Framework	High Risk	Confirmed	False Pos.	Medium	Concern	No Issue
GDPR	9	1	9	1	0	0
HIPAA	7	0	10	1	1	1
PCI-DSS	7	1	9	2	1	0
SOC2	7	1	9	1	2	0
SOX	7	1	7	1	0	0
TCPA	8	0	8	0	0	0

Domains Detected

Fintech

97.2%

Saas

92.2%

Ecommerce

76.4%

Communication

34.0%

Healthcare

16.5%

Gdpr

8.3%

Sox

5.8%

HIPAA

HHS / OCR · Fines up to $1.5M/year per category

10 findings · 10 possible FP

Possible False Positives (10)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

HIPAA-001 · Possible False Positive

No Issue Found›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is from a configuration file (.typos.toml) and consists of Philippine state abbreviations, which do not constitute individually identifiable health information under HIPAA.

Evidence

[CONFIG] .typos.toml:18 AGS = "AGS" # philippines state abbreviation [CONFIG] .typos.toml:19 AgusanDelSur = "AgusanDelSur" # philippines state abbreviation [CONFIG] .typos.toml:20 CamarinesSur = "CamarinesSur" # philippines state abbreviation [CONFIG] .typos.toml:21 DavaoDelSur = "DavaoDelSur" # philippines state abbreviation [CONFIG] .typos.toml:22 IlocosSur = "IlocosSur" # philippines state abbreviation [CONFIG] .typos.toml:23 LanaoDelSur = "LanaoDelSur" # philippines state abbreviation [CONFIG] .typos.toml:24 MaguindanaoDelSur = "MaguindanaoDelSur" # philippines state abbreviation [CONFIG] .typos.toml:25 SurigaoDelSur = "SurigaoDelSur" # philippines state abbreviation

Finding

Does this system collect, store, process, or transmit individually identifiable health information as defined under 45 CFR §160.103, and if so, are adequate technical safeguards in place to protect the confidentiality of such Protected Health Information?

Remediation

No changes are required to `.typos.toml` (lines 18-22) as the listed state abbreviations do not constitute Protected Health Information under HIPAA. If future processing by hyperswitch involves health-related transactions, a comprehensive HIPAA risk assessment must be performed to identify PHI touchpoints and avoid non-compliance with 45 CFR §160.103.

HIPAA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence primarily cites configuration and workflow files, which do not contain application source code. Furthermore, the workflow evidence explicitly mentions 'Download Encrypted TOML from S3 and Decrypt,' indicating that encryption mechanisms are in place for certain sensitive data (configuration files), rather than demonstrating a lack of encryption for PHI at rest. The `.dockerignore` entry is irrelevant.

Evidence

[CONFIG] .dockerignore:216 Thumbs.db:encryptable [CONFIG] .github/workflows/archive/connector-ui-sanity-tests.yml:85 - name: Download Encrypted TOML from S3 and Decrypt [CONFIG] .github/workflows/archive/connector-ui-sanity-tests.yml:85 - name: Download Encrypted TOML from S3 and Decrypt [CONFIG] .github/workflows/cypress-tests-runner.yml:283 - name: Download Encrypted TOML from S3 and Decrypt [CONFIG] .github/workflows/cypress-tests-runner.yml:483 - name: Download Encrypted TOML from S3 and Decrypt [CONFIG] .github/workflows/cypress-tests-runner.yml:747 - name: Download Encrypted TOML from S3 and Decrypt [CONFIG] .github/workflows/cypress-tests-runner.yml:1122 - name: Download Encrypted TOML from S3 and Decrypt [CONFIG] .github/workflows/cypress-tests-runner.yml:20 OPTIONAL_PAYMENTS_CONNECTORS_BATCH_1: "cryptopay finix nexixpay"

Finding

Is electronic Protected Health Information encrypted when stored at rest using methods consistent with NIST Special Publication 800-111, as required for addressable implementation under the HIPAA Security Rule?

Remediation

For any sensitive customer data or potential PHI referenced or processed by workflows such as `.github/workflows/cypress-tests-runner.yml`, confirm that the underlying storage (e.g., databases, S3 buckets) employs NIST SP 800-111 compliant encryption at rest (e.g., AES-256), to prevent non-compliance with the HIPAA Security Rule regarding unencrypted PHI.

HIPAA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The primary analysis identified a HIPAA encryption-in-transit risk, but the provided evidence from `.devcontainer/devcontainer.json` and `.dockerignore` consists solely of comments and ignore patterns, offering no relevant information regarding actual data transmission, encryption configurations, or the presence of Protected Health Information.

Evidence

[CONFIG] .devcontainer/devcontainer.json:1 // For format details, see https://aka.ms/devcontainer.json. For config options, see the [CONFIG] .devcontainer/devcontainer.json:2 // README at: https://github.com/devcontainers/templates/tree/main/src/docker-existing-dockerfile [CONFIG] .devcontainer/devcontainer.json:20 // Features to add to the dev container. More info: https://containers.dev/features. [CONFIG] .devcontainer/devcontainer.json:32 // Uncomment to connect as an existing user other than the container default. More info: https://aka [CONFIG] .dockerignore:1 # Created by https://www.toptal.com/developers/gitignore/api/rust,visualstudiocode,clion,dotenv,dire [CONFIG] .dockerignore:2 # Edit at https://www.toptal.com/developers/gitignore?templates=rust,visualstudiocode,clion,dotenv,d [CONFIG] .dockerignore:6 # Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839 [CONFIG] .dockerignore:84 # Comment Reason: https://github.com/joeblau/gitignore.io/issues/186#issuecomment-215987721

Finding

Are all transmissions of electronic Protected Health Information encrypted using transport-level security consistent with NIST guidelines, preventing unauthorized access during transmission across electronic communications networks?

Remediation

The evidence files `.devcontainer/devcontainer.json` and `.dockerignore` contain only comments and ignore patterns, and therefore do not provide actionable configuration specific to encryption in transit. Review actual application network communication configurations for adherence to transport-level security, consistent with NIST guidelines, to prevent unauthorized access and comply with HIPAA.

HIPAA-004 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is from the `.github/CODEOWNERS` configuration file, which defines code ownership for development workflow rather than directly indicating the presence or absence of runtime technical access controls for electronic Protected Health Information (ePHI) as required by HIPAA.

Evidence

[CONFIG] .github/CODEOWNERS:129 crates/router/src/services/authentication.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:98 crates/api_models/src/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:99 crates/api_models/src/events/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:104 crates/diesel_models/src/query/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:108 crates/diesel_models/src/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:110 crates/router/src/consts/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:117 crates/router/src/core/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:122 crates/router/src/db/user_role.rs @juspay/hyperswitch-dashboard

Finding

Does the system implement technical policies and procedures for electronic information systems that maintain electronic Protected Health Information to allow access only to those persons or software programs that have been granted access rights as specified in 45 CFR §164.312(a)(1)?

Remediation

The access control logic within `crates/router/src/services/authentication.rs` and modules like `crates/api_models/src/user_role.rs` (as referenced by `.github/CODEOWNERS`) must be reviewed and fortified to ensure only authorized persons or programs can access electronic Protected Health Information, thereby complying with 45 CFR §164.312(a)(1) to avoid HIPAA violations.

HIPAA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence points exclusively to GitHub Actions workflow configuration files, which describe CI/CD processes and health checks for services, not user session management or application code handling PHI; thus, the evidence is irrelevant to the HIPAA-005 requirement for session termination.

Evidence

[CONFIG] .github/workflows/CI-pr.yml:28 # from transient network timeouts or other issues. [CONFIG] .github/workflows/CI-push.yml:31 # from transient network timeouts or other issues. [CONFIG] .github/workflows/archive/connector-sanity-tests.yml:34 # from transient network timeouts or other issues. [CONFIG] .github/workflows/archive/connector-sanity-tests.yml:51 --health-timeout 5s [CONFIG] .github/workflows/archive/connector-ui-sanity-tests.yml:29 # from transient network timeouts or other issues. [CONFIG] .github/workflows/archive/connector-ui-sanity-tests.yml:47 --health-timeout 5s [CONFIG] .github/workflows/archive/connector-ui-sanity-tests.yml:60 --health-timeout 5s [CONFIG] .github/workflows/cypress-tests-runner.yml:230 --health-timeout 5s

Finding

Does the system implement electronic procedures that terminate an electronic session after a predetermined time of inactivity, as required for PHI-accessing interfaces under the HIPAA Security Rule?

Remediation

The cited workflow files (.github/workflows/CI-pr.yml, .github/workflows/CI-push.yml, .github/workflows/archive/connector-sanity-tests.yml, .github/workflows/archive/connector-ui-sanity-tests.yml) pertain to CI/CD automation and health checks, not user interfaces accessing PHI; therefore, no changes are required within these specific files to implement session timeout functionality for HIPAA-005 compliance.

HIPAA-006 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration and documentation files, not direct application source code, making it insufficient to confirm the *implementation* of HIPAA-compliant audit controls for ePHI.

Evidence

[CONFIG] Makefile:25 audit \ [DOCS] README.md:69 Advanced observability tools to audit, monitor, and optimize your payment costs. Detect hidden fees, [DOCS] README.md:85 Automate 2-way and 3-way reconciliation with backdated support, staggered scheduling, and customizab [DOCS] add_connector.md:647 router_env::logger::info!(connector_response=?response); [DOCS] add_connector.md:669 - Logs the response - Records the connector response for debugging via `event_builder` and `router_e [DOCS] add_connector.md:765 router_env::logger::info!(connector_response=?response); [DOCS] add_connector.md:837 router_env::logger::info!(connector_response=?response); [CONFIG] config/config.example.toml:1187 audit_events_topic = "topic" # Kafka topic to be used for Payment Audit events

Finding

Does the system implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic Protected Health Information, as required under the audit controls standard?

Remediation

If hyperswitch processes ePHI, confirm that the general audit mentions in `Makefile:25` and `README.md:69` are supported by explicit application source code demonstrating comprehensive audit logging for ePHI, including specific capture of `connector_response` as noted in `add_connector.md:647`, to comply with HIPAA audit control standards.

HIPAA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists entirely of configuration files related to Docker build exclusions and code ownership, which do not directly demonstrate a failure in limiting Protected Health Information (PHI) access or disclosure to the minimum necessary standard as required by HIPAA-007.

Evidence

[CONFIG] .dockerignore:80 # Android studio 3.1+ serialized cache file [CONFIG] .dockerignore:35 # When using Gradle or Maven with auto-import, you should exclude module files, [CONFIG] .dockerignore:241 # hyperswitch Project specific excludes [CONFIG] .dockerignore:207 # Support for Project snippet scope [CONFIG] .github/CODEOWNERS:52 crates/router/src/configs/defaults/payment_connector_required_fields.rs @juspay/hyperswitch-connecto [CONFIG] .github/CODEOWNERS:164 crates/router/src/configs/defaults/payout_required_fields.rs @juspay/hyperswitch-payouts [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:53 description: "Changing defaults affects new rows only, may cause inconsistency" [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:11 drop_column:

Finding

Does the system limit the Protected Health Information disclosed or accessed to the minimum necessary to accomplish the intended purpose, consistent with the minimum necessary standard under the Privacy Rule?

Remediation

Implement role-based access controls that restrict PHI access based on user roles and specific business purposes. Add data filtering mechanisms that automatically limit the amount of PHI returned in API responses based on the requesting user's role and the intended purpose of the request. Create audit logging to track what PHI is accessed by whom and for what purpose. Establish technical safeguards that prevent users from accessing more PHI than necessary to complete their assigned functions.

HIPAA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence from .dockerignore refers to developer IDE configuration files for cloud services, which does not directly indicate system integration handling PHI or the absence of Business Associate Agreements.

Evidence

[CONFIG] .dockerignore:15 # AWS User-specific [CONFIG] .dockerignore:16 .idea/**/aws.xml [CONFIG] .dockerignore:113 # Azure Toolkit for IntelliJ plugin [CONFIG] .dockerignore:114 # https://plugins.jetbrains.com/plugin/8053-azure-toolkit-for-intellij [CONFIG] .dockerignore:115 .idea/**/azureSettings.xml [CONFIG] .github/CODEOWNERS:188 crates/hyperswitch_connectors/src/connectors/stripe/transformers/connect.rs @juspay/hyperswitch-payo [CONFIG] .github/CODEOWNERS:31 crates/api_models/src/events/ @juspay/hyperswitch-analytics [CONFIG] .github/CODEOWNERS:32 crates/api_models/src/events.rs @juspay/hyperswitch-analytics

Finding

Does the system integrate with third-party services that may receive, maintain, or transmit Protected Health Information, and if so, is there evidence that Business Associate Agreement requirements are addressed in the code or configuration?

Remediation

The presence of AWS and Azure configuration exclusions in .dockerignore suggests potential cloud service usage; therefore, verify that all AWS and Azure integrations within hyperswitch that handle Protected Health Information have executed Business Associate Agreements. Confirming BAAs for PHI-processing cloud services is crucial to avoid HIPAA non-compliance.

HIPAA-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

All provided evidence consists of configuration files and documentation, not application source code directly demonstrating a lack of comprehensive PHI disposal policies or procedures as required by HIPAA-009.

Evidence

[CONFIG] .dockerignore:127 # temporary files which can be created if a process still has a handle open of a deleted file [DOCS] .github/PULL_REQUEST_TEMPLATE.md:39 that will have little conversation). [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:15 delete_data: [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:16 pattern: 'DELETE\s+FROM\s+' [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:63 - delete_data [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:80 - delete_data [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:97 - delete_data [CONFIG] .github/workflows/cypress-tests-runner.yml:151 retention-days: 1

Finding

Does the system implement policies and procedures to address the final disposition of electronic Protected Health Information and the hardware or electronic media on which it is stored, as well as removal of PHI before media is available for reuse?

Remediation

Document policies and procedures explaining how data deletion patterns, such as those defined in `.github/api-migration-compatibility/migration-rules.yaml`, are part of a comprehensive data retention and disposal strategy for PHI, including secure media sanitization, to avoid non-compliance with HIPAA-009 regarding the final disposition of ePHI and media.

HIPAA-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files (.dockerignore, .github/CODEOWNERS) which do not directly confirm the presence or absence of HIPAA-required procedures for breach detection, reporting, or emergency access to PHI.

Evidence

[CONFIG] .dockerignore:143 .LSOverride [CONFIG] .dockerignore:182 # These are backup files generated by rustfmt [CONFIG] .dockerignore:251 monitoring/*.tmp/ [CONFIG] .github/CODEOWNERS:155 monitoring/ @juspay/hyperswitch-infra [CONFIG] .github/CODEOWNERS:77 crates/external_services/src/grpc_client/health_check_client.rs @juspay/hyperswitch-routing [CONFIG] .github/workflows/release-stable-version.yml:151 # Override git-cliff tag pattern to only consider SemVer tags [CONFIG] .gitignore:144 .LSOverride [CONFIG] .gitignore:182 # These are backup files generated by rustfmt

Finding

Does the system implement procedures for detecting, reporting, and responding to suspected or known security incidents involving electronic Protected Health Information, and does it provide for emergency access to PHI during system disruptions?

Remediation

Evaluate if the exclusion of `monitoring/*.tmp/` in `.dockerignore` could impede incident forensics necessary for HIPAA incident response. Formalize incident detection and reporting procedures, clearly defining responsibilities for monitoring activities managed by @juspay/hyperswitch-infra and health checks impacting routing by @juspay/hyperswitch-routing, to satisfy HIPAA Security Rule requirements for security incident procedures (164.308(a)(6)).

PCI-DSS

PCI SSC · Fines $5K-$100K/month

10 findings · 9 possible FP

PCIDSS-004

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The `aws/hyperswitch_aws_setup.sh` script directly defines network security configurations, specifically creating ingress rules for common ports (80 and 22) and associating a security group with an RDS instance, which is a high-risk area for PCI-DSS compliance if segmentation and least privilege are not strictly enforced.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] aws/hyperswitch_aws_setup.sh:167 --vpc-security-group-ids $RDS_SG_ID)" [CONFIG] aws/hyperswitch_aws_setup.sh:51 echo "Creating Security Group ingress for port 80..." [CONFIG] aws/hyperswitch_aws_setup.sh:53 echo "$(aws ec2 authorize-security-group-ingress \ [CONFIG] aws/hyperswitch_aws_setup.sh:60 echo "Security Group ingress for port 80 CREATED.\n" [CONFIG] aws/hyperswitch_aws_setup.sh:62 echo "Creating Security Group ingress for port 22..." [CONFIG] aws/hyperswitch_aws_setup.sh:64 echo "$(aws ec2 authorize-security-group-ingress \ [CONFIG] aws/hyperswitch_aws_setup.sh:71 echo "Security Group ingress for port 22 CREATED.\n" [CONFIG] aws/hyperswitch_aws_setup.sh:92 echo "$(aws ec2 authorize-security-group-ingress \

Finding

Does the system implement network segmentation to isolate the cardholder data environment (CDE) from other network segments, reducing the scope of PCI DSS compliance as described in Requirement 1?

Remediation

Remediation refined by Gemini review

Possible False Positives (9)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

PCIDSS-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (.clippy.toml, .github/api-migration-compatibility/migration-rules.yaml) which do not directly demonstrate the storage, processing, or lack of protection of cardholder data as required by PCI DSS Requirement 3.5.

Evidence

[CONFIG] .clippy.toml:3 allow-panic-in-tests = true [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:19 truncate_table: [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:20 pattern: 'TRUNCATE\s+' [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:64 - truncate_table [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:81 - truncate_table [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:98 - truncate_table [CONFIG] .github/cocogitto-changelog-template:15 {% set from_shorthand = from.id | truncate(length=7, end="") -%} [CONFIG] .github/cocogitto-changelog-template:16 {% set to_shorthand = version.id | truncate(length=7, end="") -%}

Finding

Does this system store, process, or transmit cardholder data including primary account numbers (PAN), and if so, are adequate protections in place to render stored PAN unreadable, as required under PCI DSS Requirement 3.5?

Remediation

Review the `truncate_table` pattern in `.github/api-migration-compatibility/migration-rules.yaml` to confirm it only applies to non-cardholder data tables, or that any PAN data subject to truncation is already tokenized or encrypted prior to operation. Failure to verify this could lead to non-compliance with PCI DSS Requirement 3.5 regarding rendering stored PAN unreadable.

PCIDSS-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of configuration files (.devcontainer/devcontainer.json and .dockerignore), with the relevant line `Thumbs.db:encryptable` in .dockerignore referring to a Windows system thumbnail database file. This file is explicitly ignored from the Docker context and has no direct relevance to the encryption of cardholder data in transit or at rest within the application as required by PCI DSS.

Evidence

[CONFIG] .devcontainer/devcontainer.json:1 // For format details, see https://aka.ms/devcontainer.json. For config options, see the [CONFIG] .devcontainer/devcontainer.json:2 // README at: https://github.com/devcontainers/templates/tree/main/src/docker-existing-dockerfile [CONFIG] .devcontainer/devcontainer.json:20 // Features to add to the dev container. More info: https://containers.dev/features. [CONFIG] .devcontainer/devcontainer.json:32 // Uncomment to connect as an existing user other than the container default. More info: https://aka [CONFIG] .dockerignore:216 Thumbs.db:encryptable [CONFIG] .dockerignore:1 # Created by https://www.toptal.com/developers/gitignore/api/rust,visualstudiocode,clion,dotenv,dire [CONFIG] .dockerignore:2 # Edit at https://www.toptal.com/developers/gitignore?templates=rust,visualstudiocode,clion,dotenv,d [CONFIG] .dockerignore:6 # Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

Finding

Is cardholder data encrypted using strong cryptography during transmission over open public networks and when stored at rest, consistent with PCI DSS Requirements 3.5 and 4.2?

Remediation

Given that the entry `Thumbs.db:encryptable` in `.dockerignore` (line 216) appears to be misinterpreted by automated analysis tools as relevant to cardholder data encryption, consider adding a clarifying comment next to this line to explicitly state its irrelevance to PCI-DSS scope, to prevent future false positives and avoid perceived non-compliance with PCI DSS Requirements 3.5 and 4.2.

PCIDSS-003 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence primarily cites a configuration file (.github/CODEOWNERS) which indicates ownership of user role-related source code files, but does not directly provide evidence of how those roles are implemented or if they fail to restrict access to cardholder data as per PCI DSS Requirement 7.

Evidence

[CONFIG] .github/CODEOWNERS:98 crates/api_models/src/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:99 crates/api_models/src/events/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:104 crates/diesel_models/src/query/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:108 crates/diesel_models/src/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:110 crates/router/src/consts/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:117 crates/router/src/core/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:122 crates/router/src/db/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:127 crates/router/src/routes/user_role.rs @juspay/hyperswitch-dashboard

Finding

Does the system restrict access to cardholder data to only those individuals and systems whose job requires such access, implementing role-based access controls consistent with PCI DSS Requirement 7?

Remediation

Review the access control logic within `crates/api_models/src/user_role.rs` and other `user_role.rs` files referenced in `.github/CODEOWNERS` to confirm that role-based access controls are adequately defined and enforced to restrict access to cardholder data. This verification is essential to prevent non-compliance with PCI DSS Requirement 7 regarding access control.

PCIDSS-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, solely from the `.dockerignore` file and pertaining to developer tool exclusions and IDE patches, does not directly indicate a lack of vulnerability management practices required by PCI DSS Requirement 6.

Evidence

[CONFIG] .dockerignore:95 # SonarQube Plugin [CONFIG] .dockerignore:96 # https://plugins.jetbrains.com/plugin/7238-sonarqube-community-plugin [CONFIG] .dockerignore:83 ### CLion Patch ### [CONFIG] .dockerignore:168 ### macOS Patch ### [CONFIG] .dockerignore:202 ### VisualStudioCode Patch ### [CONFIG] .gitattributes:2 *.patch text eol=lf [CONFIG] .github/CODEOWNERS:55 crates/router/src/types/api/connector_mapping.rs @juspay/hyperswitch-connector [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:9 description: "Dropping a table removes data and breaks existing queries"

Finding

Does the system demonstrate evidence of vulnerability management practices including regular patching, dependency updates, and vulnerability scanning, consistent with PCI DSS Requirement 6?

Remediation

Review the `.dockerignore` file, specifically lines 95-96 referencing the `SonarQube Plugin`, to confirm that the exclusion of these files from the Docker build context does not impede the integration or effectiveness of vulnerability scanning in the CI/CD pipeline. Inadequate vulnerability scanning throughout the SDLC for containerized applications risks non-compliance with PCI DSS Requirement 6.

PCIDSS-006 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence, which consists of entries in a `.dockerignore` file excluding local SonarLint IDE configuration files, does not indicate a lack of formal security testing controls or static analysis within the CI/CD pipeline, as required by PCI DSS; instead, it reflects standard practice for not including development tooling artifacts in Docker builds.

Evidence

[CONFIG] .dockerignore:68 # SonarLint plugin [CONFIG] .dockerignore:69 .idea/sonarlint/ [CONFIG] .dockerignore:91 # Sonarlint plugin [CONFIG] .dockerignore:92 # https://plugins.jetbrains.com/plugin/7973-sonarlint [CONFIG] .dockerignore:93 .idea/**/sonarlint/ [CONFIG] .dockerignore:68 # SonarLint plugin [CONFIG] .dockerignore:69 .idea/sonarlint/ [CONFIG] .dockerignore:91 # Sonarlint plugin

Finding

Does the system implement security testing controls including code review, static analysis, and penetration testing practices, as required under PCI DSS Requirement 6.3 and 11.4?

Remediation

Review the project's CI/CD pipeline and `.dockerignore` file, specifically lines 68-93 related to SonarLint, to verify that excluding local IDE static analysis configurations does not lead to the omission of formal, automated static application security testing (SAST) in the build process, as mandated by PCI DSS Requirement 6.3.

PCIDSS-007 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files and documentation, which do not directly demonstrate the implementation of audit trail mechanisms in source code required by PCI DSS Requirement 10 for logging cardholder data access or administrative actions.

Evidence

Finding

Does the system implement audit trail mechanisms that record all individual access to cardholder data, all actions taken by any individual with root or administrative privileges, and all access to audit trails, as required under PCI DSS Requirement 10?

Remediation

For PCI DSS Requirement 10 compliance, the system's actual source code, not just documentation like `add_connector.md` referencing `router_env::logger::info!`, must explicitly implement comprehensive audit logging of all individual cardholder data access and administrative actions, detailing user, timestamp, and data accessed, to prevent non-compliance penalties.

PCIDSS-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of documentation and a configuration file, which mention 'vault' and 'kms' respectively, but does not provide application source code demonstrating the implementation of cryptographic key management procedures (generation, distribution, storage, rotation, destruction) as required by PCI DSS 3.6 and 3.7.

Evidence

[CONFIG] .typos.toml:115 kms = "kms" # Key management service [DOCS] README.md:76 - **Vault** [DOCS] README.md:77 A PCI-compliant vault service to store cards, tokens, wallets, and bank credentials. Provides a unif [DOCS] README.md:78 _[Read more](https://docs.hyperswitch.io/about-hyperswitch/payments-modules/vault)_ [DOCS] README.md:173 Hyperswitch is a commercial open-source payments stack purpose-built for scale, flexibility, and dev [CONFIG] api-reference/docs.json:500 "group": "Hyperswitch Card Vault", [DOCS] api-reference/introduction.mdx:19 <Card title="Save a payment method" icon="vault" iconType="regular" horizontal={false} href="https:/ [DOCS] api-reference/locker-api-reference/locker-general-purpose-storage/add-data-in-locker.mdx:2 openapi: locker-v2 post /api/v2/vault/add

Finding

Does the system implement cryptographic key management procedures including key generation, distribution, storage, rotation, and destruction, consistent with PCI DSS Requirement 3.6 and 3.7?

Remediation

Update `README.md` (specifically the 'Vault' section, or the linked documentation at `https://docs.hyperswitch.io/about-hyperswitch/payments-modules/vault`) to explicitly detail the cryptographic key management procedures implemented by Hyperswitch, covering key generation, distribution, storage, rotation, and destruction. Clearly outlining these practices is essential to demonstrate compliance with PCI DSS Requirements 3.6 and 3.7 and prevent regulatory non-compliance.

PCIDSS-009 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files (.github/CODEOWNERS) and documentation (.github/PULL_REQUEST_TEMPLATE.md), which suggest the existence of third-party payment integrations but do not directly cite application source code or confirm the absence of specific third-party management controls as per the defined verdict rules.

Evidence

[CONFIG] .github/CODEOWNERS:188 crates/hyperswitch_connectors/src/connectors/stripe/transformers/connect.rs @juspay/hyperswitch-payo [CONFIG] .github/CODEOWNERS:184 crates/hyperswitch_connectors/src/connectors/adyenplatform/ @juspay/hyperswitch-payouts [CONFIG] .github/CODEOWNERS:185 crates/hyperswitch_connectors/src/connectors/adyenplatform.rs @juspay/hyperswitch-payouts [CONFIG] .github/CODEOWNERS:190 crates/router/tests/connectors/adyenplatform.rs @juspay/hyperswitch-payouts [DOCS] .github/PULL_REQUEST_TEMPLATE.md:45 Did you write an integration/unit/API test to verify the code changes? [CONFIG] .github/data/cards_info.csv:1 card_iin,card_issuer,card_network,card_type,card_subtype,card_issuing_country,bank_code_id,bank_code [CONFIG] .github/data/cards_info.csv:7 424242,STRIPE PAYMENTS UK LIMITED,Visa,CREDIT,,UNITEDKINGDOM,,,GB,2015-07-22 16:41:32,2025-11-04 15: [CONFIG] .github/data/gateway_status_map.csv:6 stripe,Payment,Authorize,card_declined,Your card was declined.,failure,,do_default,2025-12-02 13:36:

Finding

Does the system manage third-party service providers that have access to cardholder data with appropriate controls, agreements, and monitoring, consistent with PCI DSS Requirement 12.8?

Remediation

Given the use of Stripe and Adyen connectors referenced in `.github/CODEOWNERS`, formalize a third-party service provider management program by documenting written agreements with security requirements, annual PCI compliance validation, and ongoing monitoring for these and all other payment processors, as required by PCI DSS Requirement 12.8 to prevent potential regulatory fines.

PCIDSS-010 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files and documentation, which do not directly demonstrate the presence or absence of a comprehensive incident response plan as required by PCI DSS Requirement 12.10; these files are insufficient to confirm the finding.

Evidence

[CONFIG] .dockerignore:251 monitoring/*.tmp/ [CONFIG] .github/CODEOWNERS:77 crates/external_services/src/grpc_client/health_check_client.rs @juspay/hyperswitch-routing [CONFIG] .github/CODEOWNERS:155 monitoring/ @juspay/hyperswitch-infra [DOCS] .github/PULL_REQUEST_TEMPLATE.md:23 Provide links to the files with corresponding changes. [CONFIG] .gitignore:252 monitoring/*.tmp/ [CONFIG] Dockerfile:52 # RUN_ENV decides the corresponding config file to be used [CONFIG] LICENSE:159 incidental, or consequential damages of any character arising as a [DOCS] README.md:113 - **Full**: Includes monitoring + schedulers

Finding

Does the system implement an incident response plan that addresses suspected or confirmed cardholder data breaches, including detection, containment, and notification procedures, as required under PCI DSS Requirement 12.10?

Remediation

Verify that the ownership assignments for the `monitoring/` directory in `.github/CODEOWNERS:155` and the exclusion of temporary monitoring files in `.dockerignore:251` and `.gitignore:252` are explicitly referenced and integrated into the organization's formal PCI DSS incident response plan, otherwise the system risks non-compliance with PCI DSS Requirement 12.10.

SOC2

AICPA · Loss of enterprise contracts

10 findings · 9 possible FP

SOC2-010

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The primary analysis correctly identified a critical gap in documented security policies (SOC2-010). The evidence cited, references to 'Contributing Guidelines' in issue templates, does not fulfill the requirement for comprehensive security policies such as acceptable use, data classification, or access management, thus confirming the identified lack of appropriate documentation within the repository's visible scope.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:88 id: read-contributing-guidelines [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:90 label: Have you read the Contributing Guidelines? [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:92 - label: I have read the [Contributing Guidelines](https://github.com/juspay/hyperswitch/blob/main/d [CONFIG] .github/ISSUE_TEMPLATE/feature_request.yml:41 id: read-contributing-guidelines [CONFIG] .github/ISSUE_TEMPLATE/feature_request.yml:43 label: Have you read the Contributing Guidelines? [CONFIG] .github/ISSUE_TEMPLATE/feature_request.yml:45 - label: I have read the [Contributing Guidelines](https://github.com/juspay/hyperswitch/blob/main/d [DOCS] README.md:193 ## Contributing [DOCS] README.md:197 Please read our [contributing guidelines](https://github.com/juspay/hyperswitch/blob/main/docs/CONTR

Finding

Does the system demonstrate evidence of documented security policies, including acceptable use, data classification, and access management policies, as required under CC1.1 for the entity's commitment to integrity and ethical values?

Remediation

Remediation refined by Gemini review

Possible False Positives (9)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOC2-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists entirely of configuration files which, while relevant to the management of code modules dealing with authentication, do not directly demonstrate the implementation or absence of user authentication controls, making it a flag for review rather than a confirmed risk.

Evidence

[CONFIG] .github/CODEOWNERS:129 crates/router/src/services/authentication.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:132 crates/router/src/services/jwt.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:90 crates/router/src/core/payments/tokenization.rs @juspay/hyperswitch-payment-methods [CONFIG] .github/git-cliff-changelog.toml:54 commit_preprocessors = [ [CONFIG] .github/workflows/CI-pr.yml:39 - name: Generate a token [CONFIG] .github/workflows/CI-pr.yml:41 id: generate_token [CONFIG] .github/workflows/CI-pr.yml:42 uses: actions/create-github-app-token@v1 [CONFIG] .github/workflows/CI-pr.yml:47 - name: Checkout repository with token

Finding

Does the system implement logical access security controls over user authentication that are suitably designed and operating effectively to restrict access to authorized users, consistent with the Common Criteria CC6.1 requirement for logical and physical access controls?

Remediation

For code modules specified in `.github/CODEOWNERS` (e.g., `authentication.rs`, `jwt.rs`) and token generation processes within `.github/workflows/CI-pr.yml`, provide comprehensive documentation detailing implemented user authentication controls (MFA, password policies, session management, and access control matrices) to ensure adherence to SOC2 CC6.1 requirements for logical access security.

SOC2-002 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of configuration files (.dockerignore, .github/CODEOWNERS) which reference source code files related to user roles, but does not provide actual application code or sufficient context to determine whether the role-based access controls are improperly implemented or present a compliance risk.

Evidence

[CONFIG] .dockerignore:207 # Support for Project snippet scope [CONFIG] .github/CODEOWNERS:98 crates/api_models/src/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:99 crates/api_models/src/events/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:104 crates/diesel_models/src/query/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:108 crates/diesel_models/src/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:110 crates/router/src/consts/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:117 crates/router/src/core/user_role.rs @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:122 crates/router/src/db/user_role.rs @juspay/hyperswitch-dashboard

Finding

Does the system implement role-based or attribute-based access controls that restrict system functions and data access based on authorized user roles, consistent with the principle of least privilege as required under CC6.3?

Remediation

Provide access to the actual source code content of the identified role-based access control files to enable verification of proper implementation. The analysis should include reviewing the role definition structures, permission matrices, access enforcement logic, and validation that system functions are appropriately restricted based on user roles with least privilege principles applied.

SOC2-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of comments within development environment configuration files (`.devcontainer/devcontainer.json`) and a `.dockerignore` file, which do not directly indicate a lack of encryption for data in transit in a production system.

Evidence

Finding

Does the system protect data during transmission over networks using encryption or other equivalent security measures, consistent with the CC6.7 requirement for protection of information during transmission?

Remediation

Review the `.devcontainer/devcontainer.json` and `.dockerignore` files to confirm that no development environment configurations or ignore patterns inadvertently prevent or disable TLS/HTTPS encryption for data in transit. Explicit configurations within these files should enforce secure protocols for internal and external communications to comply with SOC2 CC6.7.

SOC2-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (`.dockerignore`, `.github/CODEOWNERS`, `.github/ISSUE_TEMPLATE`) which do not directly demonstrate a lack of logging and monitoring mechanisms; instead, they indicate the presence of a 'monitoring/' directory, designated ownership for it, and the expectation of log data in bug reports.

Evidence

[CONFIG] .dockerignore:251 monitoring/*.tmp/ [CONFIG] .dockerignore:251 monitoring/*.tmp/ [CONFIG] .github/CODEOWNERS:155 monitoring/ @juspay/hyperswitch-infra [CONFIG] .github/CODEOWNERS:155 monitoring/ @juspay/hyperswitch-infra [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:59 placeholder: Providing context (e.g. request-response bodies, stack trace or log data) helps us come [CONFIG] .github/workflows/CI-pr.yml:31 # Don't emit giant backtraces in the CI logs. [CONFIG] .github/workflows/CI-pr.yml:32 RUST_BACKTRACE: short [CONFIG] .github/workflows/CI-push.yml:34 # Don't emit giant backtraces in the CI logs.

Finding

Does the system implement logging, monitoring, and alerting mechanisms that detect and record security events, anomalies, and unauthorized activities, as required under CC7.2 for monitoring system components for anomalies?

Remediation

Review the comprehensiveness of security event logging and monitoring processes within the `monitoring/` infrastructure, owned by `@juspay/hyperswitch-infra` as per `.github/CODEOWNERS:155`, to ensure it covers all security events, anomalies, and unauthorized activities required by SOC2 CC7.2. Ensure the 'log data' referenced in `.github/ISSUE_TEMPLATE/bug_report.yml:59` is sufficient for detecting and investigating security incidents, preventing potential non-compliance.

SOC2-005 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (.toml, .json, .dockerignore), which do not directly demonstrate the absence or inadequacy of change management controls such as version control, code review processes, or controlled deployment procedures as required by CC8.1.

Evidence

[CONFIG] .deepsource.toml:1 version = 1 [CONFIG] .devcontainer/devcontainer.json:29 // Configure tool-specific properties. [CONFIG] .dockerignore:8 # User-specific stuff [CONFIG] .dockerignore:15 # AWS User-specific [CONFIG] .dockerignore:241 # hyperswitch Project specific excludes [CONFIG] .dockerignore:253 config/production.toml [CONFIG] .github/CODEOWNERS:20 migrations/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:21 v2_migrations/ @juspay/hyperswitch-framework

Finding

Does the system demonstrate evidence of change management controls including version control, code review processes, and controlled deployment procedures, as required under CC8.1 for managing changes to infrastructure, data, software, and procedures?

Remediation

Implement and document formal code review processes with approval workflows, establish controlled deployment procedures with staging environments and rollback capabilities, and create comprehensive change management documentation that covers all changes to infrastructure, data, software, and procedures. Add pull request templates, deployment checklists, and change approval matrices to demonstrate systematic change control processes beyond the basic CODEOWNERS file currently in place.

SOC2-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence consists solely of configuration and documentation files (CODEOWNERS, PR template, CI config, Dockerfile, LICENSE) and does not include application source code or specific details directly demonstrating the implementation or absence of incident detection, response, or recovery procedures.

Evidence

[CONFIG] .github/CODEOWNERS:77 crates/external_services/src/grpc_client/health_check_client.rs @juspay/hyperswitch-routing [DOCS] .github/PULL_REQUEST_TEMPLATE.md:23 Provide links to the files with corresponding changes. [CONFIG] .github/workflows/CI-pr.yml:232 name: Spell check specific critical directories [CONFIG] Dockerfile:52 # RUN_ENV decides the corresponding config file to be used [CONFIG] LICENSE:159 incidental, or consequential damages of any character arising as a [DOCS] add_connector.md:413 Response mapping is a critical component of connector implementation that translates payment process [DOCS] add_connector.md:550 #### Critical Response Fields [DOCS] add_connector.md:563 Each critical response field requires specific implementation patterns to ensure consistent behavior

Finding

Does the system implement incident detection, response, and recovery procedures that enable timely identification and remediation of security incidents, consistent with CC7.3 requirements for evaluating security events and CC7.4 for responding to identified incidents?

Remediation

Review `crates/external_services/src/grpc_client/health_check_client.rs` and its integration with monitoring and alerting systems to ensure that critical health failures trigger immediate security incident detection. Without robust integration of health monitoring into a formal incident response process, the system risks non-compliance with SOC2 CC7.3 requirements for timely security event evaluation.

SOC2-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of config files showing `Cargo.lock` is tracked and owned, which indicates a form of dependency management rather than directly proving a lack of a risk assessment or management program required by SOC2 CC9.2.

Evidence

[CONFIG] .dockerignore:178 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries [CONFIG] .dockerignore:179 # More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html [CONFIG] .dockerignore:180 !Cargo.lock [CONFIG] .github/CODEOWNERS:24 Cargo.toml @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:25 Cargo.lock @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:55 crates/router/src/types/api/connector_mapping.rs @juspay/hyperswitch-connector [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:9 description: "Dropping a table removes data and breaks existing queries" [CONFIG] .github/api-migration-compatibility/migration-rules.yaml:13 description: "Dropping a column breaks applications expecting it"

Finding

Does the system assess and manage risks associated with third-party vendors, libraries, and service providers, including dependency vulnerability management, consistent with CC9.2 requirements for risk assessment of third-party service providers?

Remediation

To adhere to SOC2 CC9.2 for risk assessment of third-party service providers, the team assigned ownership of `Cargo.lock` in `.github/CODEOWNERS` (@juspay/hyperswitch-framework) should integrate automated vulnerability scanning of this dependency lock file into the CI/CD pipeline, ensuring continuous management of risks associated with third-party libraries.

SOC2-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files (.devcontainer.json, .dockerignore) which do not indicate a lack of production data backup and recovery controls, but rather show exclusion of temporary development-related files from Docker builds, making them irrelevant to the SOC2-008 criterion.

Evidence

[CONFIG] .devcontainer/devcontainer.json:32 // Uncomment to connect as an existing user other than the container default. More info: https://aka [CONFIG] .dockerignore:182 # These are backup files generated by rustfmt [CONFIG] .dockerignore:220 # Dump file [CONFIG] .dockerignore:221 *.stackdump [CONFIG] .dockerignore:72 com_crashlytics_export_strings.xml [CONFIG] .dockerignore:5 # Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebS [CONFIG] .dockerignore:100 # https://plugins.jetbrains.com/plugin/7896-markdown-navigator-enhanced [CONFIG] .dockerignore:127 # temporary files which can be created if a process still has a handle open of a deleted file

Finding

Does the system implement data backup, replication, and recovery controls that ensure availability and recoverability of data, consistent with the A1.2 criterion for recovery of infrastructure and data to meet objectives?

Remediation

Implement comprehensive data backup and recovery controls including: automated backup procedures with defined schedules and retention policies, database replication configurations, disaster recovery runbooks, backup verification and testing procedures, and recovery time/point objectives documentation. These controls should be implemented in infrastructure configuration files, documented in operational procedures, and include automated testing of backup and recovery processes to ensure data availability requirements are met.

SOC2-009 · Possible False Positive

Pattern of Concern›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files, including an example configuration where multi-factor authentication is not forced by default, which, while concerning, does not definitively confirm the production environment's enforcement policy required for SOC2 compliance.

Evidence

[CONFIG] .dockerignore:159 .com.apple.timemachine.donotpresent [CONFIG] .gitignore:159 .com.apple.timemachine.donotpresent [CONFIG] aws/beta_schema.sql:216 'otp', [CONFIG] config/config.example.toml:502 two_factor_auth_expiry_in_secs = 300 # Number of seconds after which 2FA should be done again if doi [CONFIG] config/config.example.toml:505 force_two_factor_auth = false # Whether to force two factor authentication for all users [CONFIG] config/config.example.toml:502 two_factor_auth_expiry_in_secs = 300 # Number of seconds after which 2FA should be done again if doi [CONFIG] config/config.example.toml:503 totp_issuer_name = "Hyperswitch" # Name of the issuer for TOTP [CONFIG] config/config.example.toml:503 totp_issuer_name = "Hyperswitch" # Name of the issuer for TOTP

Finding

Does the system implement or support multi-factor authentication for user access, particularly for privileged accounts and administrative interfaces, consistent with CC6.1 requirements for logical access security?

Remediation

Modify `config/config.example.toml` line 505 by changing `force_two_factor_auth = false` to `true` to establish a secure default for MFA enforcement. This change helps ensure multi-factor authentication is consistently required for user access, aligning with SOC2 CC6.1 requirements for logical access security.

SOX

SEC / PCAOB · Criminal penalties, delisting

8 findings · 7 possible FP

SOX-005

High Risk›

Regulatory Standard

Gemini Verification

CONFIRMED

The `.github/CODEOWNERS` entries directly indicate that a single team has ownership over critical financial transaction workflow and authorization source code, which is a clear segregation of duties risk for development and approval functions in a fintech context.

Gemini 2.5 Flash · Confidence: HIGH

Evidence

[CONFIG] .github/CODEOWNERS:89 crates/router/src/workflows/payment_method_status_update.rs @juspay/hyperswitch-payment-methods [CONFIG] .github/CODEOWNERS:166 crates/router/src/workflows/attach_payout_account_workflow.rs @juspay/hyperswitch-payouts [CONFIG] .github/CODEOWNERS:130 crates/router/src/services/authorization @juspay/hyperswitch-dashboard [CONFIG] .github/CODEOWNERS:131 crates/router/src/services/authorization.rs @juspay/hyperswitch-dashboard [CONFIG] .github/data/cards_info.csv:7 424242,STRIPE PAYMENTS UK LIMITED,Visa,CREDIT,,UNITEDKINGDOM,,,GB,2015-07-22 16:41:32,2025-11-04 15: [CONFIG] .github/git-cliff-changelog.toml:92 # limit the number of commits included in the changelog. [CONFIG] .github/git-cliff-changelog.toml:93 # limit_commits = 42 [CONFIG] .github/workflows/CI-pr.yml:10 group: ${{ github.workflow }}-${{ github.ref }}

Finding

Does the system implement segregation of duties controls that prevent any single individual from having the ability to both authorize and execute financial transactions, or to both develop and deploy changes to financial systems?

Remediation

Remediation refined by Gemini review

Possible False Positives (7)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

SOX-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided consists solely of configuration files (.dockerignore, .github/CODEOWNERS, .github/ISSUE_TEMPLATE) and does not directly cite application source code files to confirm the presence or absence of SOX financial data integrity controls.

Evidence

[CONFIG] .dockerignore:81 .idea/caches/build_file_checksums.ser [CONFIG] .github/CODEOWNERS:61 crates/router/src/core/connector_validation.rs @juspay/hyperswitch-connector [CONFIG] .github/CODEOWNERS:64 crates/hyperswitch_constraint_graph @juspay/hyperswitch-routing [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:20 validations: [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:29 validations: [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:38 validations: [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:51 validations: [CONFIG] .github/ISSUE_TEMPLATE/bug_report.yml:60 validations:

Finding

Does the system implement controls to ensure the integrity, accuracy, and completeness of financial data and transactions, consistent with SOX Section 302 requirements for management certification of financial statements?

Remediation

The primary analysis flags validation-related config files like `.github/CODEOWNERS` (referencing `connector_validation.rs`) and `.github/ISSUE_TEMPLATE` (mentioning 'validations'). For these related code areas, document and verify that robust controls for financial data integrity, including automated validation rules and audit logging, are fully implemented and auditable, to ensure compliance with SOX Section 302.

SOX-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cites only `.github/CODEOWNERS` files, which are configuration files defining code ownership and review processes, not direct evidence of implemented runtime access controls to financial systems or their deficiencies. While `user_role.rs` files are critical, their ownership definition in `CODEOWNERS` indicates a change control process, not a direct SOX 404 access control vulnerability.

Evidence

Finding

Does the system implement access controls that restrict access to financial systems and data to authorized personnel, with appropriate authentication and authorization mechanisms, as required under SOX Section 404 internal controls?

Remediation

Validate that the `@juspay/hyperswitch-dashboard` team, specified in `.github/CODEOWNERS` for `crates/*/user_role.rs`, rigorously applies least privilege and segregation of duties principles when reviewing and approving changes that define user roles impacting financial system access, to meet SOX Section 404 requirements for internal controls over financial reporting.

SOX-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited, consisting solely of `.dockerignore` entries for local history files and a line from a GitHub issue template concerning changelogs, bears no relevance to the application's capability to maintain a complete and tamper-evident audit trail of financial transactions required under SOX Section 802. This evidence does not support the finding of a high risk in audit trail functionality.

Evidence

[CONFIG] .dockerignore:196 # Local History for Visual Studio Code [CONFIG] .dockerignore:197 .history/ [CONFIG] .dockerignore:203 # Ignore all local history of files [CONFIG] .dockerignore:204 .history [CONFIG] .github/ISSUE_TEMPLATE/feature_request.yml:11 2. Check the changelog file to confirm that the feature hasn't been added for an upcoming release: h [CONFIG] .github/cocogitto-changelog-template:47 **Full Changelog:** [`{{ from.tag ~ "..." ~ version.tag }}`]({{ compare_base_url ~ from.tag ~ "..." [CONFIG] .github/cocogitto-changelog-template:49 **Full Changelog:** [`{{ from.id ~ "..." ~ version.tag }}`]({{ compare_base_url ~ from.id ~ "..." ~ [CONFIG] .github/cocogitto-changelog-template:55 **Full Changelog:** [`{{ from_shorthand ~ "..." ~ to_shorthand }}`]({{ compare_base_url ~ from_short

Finding

Does the system maintain a complete and tamper-evident audit trail of all financial transactions, modifications, and access events, sufficient to support the audit requirements under SOX Section 802?

Remediation

Implement comprehensive audit logging functionality that captures all financial transactions, data modifications, and system access events with immutable timestamps, user identification, and cryptographic integrity controls. Add database audit triggers, application-level transaction logging, and tamper-evident storage mechanisms that meet SOX requirements for financial audit trails. Ensure all audit logs are automatically generated, cannot be altered without detection, and include sufficient detail to reconstruct any financial transaction or data change.

SOX-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The cited evidence consists solely of config file comments and a version declaration, none of which directly demonstrate a lack of comprehensive change management controls for SOX compliance.

Evidence

[CONFIG] .deepsource.toml:1 version = 1 [CONFIG] .devcontainer/devcontainer.json:29 // Configure tool-specific properties. [CONFIG] .devcontainer/devcontainer.json:27 // "postCreateCommand": "cat /etc/os-release", [CONFIG] .dockerignore:8 # User-specific stuff [CONFIG] .dockerignore:15 # AWS User-specific [CONFIG] .dockerignore:241 # hyperswitch Project specific excludes [CONFIG] .dockerignore:253 config/production.toml [CONFIG] .github/CODEOWNERS:20 migrations/ @juspay/hyperswitch-framework

Finding

Does the system implement change management controls for software that processes financial data, including version control, code review, testing, and controlled deployment, consistent with SOX IT general controls?

Remediation

Review `.deepsource.toml` to ensure it mandates specific code quality and security analysis checks, rather than just a version number, to strengthen the testing phase of change management. Additionally, `.devcontainer/devcontainer.json` needs explicit configuration for standardized development environments, beyond comments, to ensure consistent testing and controlled deployment practices, thereby mitigating SOX IT general control risks.

SOX-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cites `retention-days: 1` in CI/CD workflow configurations and `.dockerignore` entries for temporary `rustfmt` backup files, which are temporary build/test artifacts and development tool outputs, not financial records or audit documentation subject to SOX Section 802's 7-year retention requirement.

Evidence

[CONFIG] .dockerignore:182 # These are backup files generated by rustfmt [CONFIG] .github/workflows/cypress-tests-runner.yml:151 retention-days: 1 [CONFIG] .github/workflows/cypress-tests-runner.yml:209 retention-days: 1 [CONFIG] .github/workflows/cypress-tests-runner.yml:402 retention-days: 1 [CONFIG] .github/workflows/cypress-tests-runner.yml:606 retention-days: 1 [CONFIG] .github/workflows/cypress-tests-runner.yml:615 retention-days: 1 [CONFIG] .github/workflows/cypress-tests-runner.yml:857 retention-days: 1 [CONFIG] .github/workflows/cypress-tests-runner.yml:866 retention-days: 1

Finding

Does the system implement data retention policies that preserve financial records, audit work papers, and supporting documentation for the minimum retention period required under SOX Section 802 (not less than 7 years)?

Remediation

The `retention-days: 1` settings in `.github/workflows/cypress-tests-runner.yml` and the `.dockerignore` entry for `rustfmt` backup files are for temporary CI/CD artifacts and development tool outputs, not financial records. No changes are required to these specific files for SOX Section 802 compliance; instead, focus retention efforts on actual financial data repositories to avoid penalties.

SOX-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited is solely a `.github/CODEOWNERS` configuration file, which defines code review ownership for specific paths but does not itself constitute or demonstrate the absence of comprehensive internal control documentation over financial reporting required by SOX 404(a), which would typically reside in separate compliance documents.

Evidence

[CONFIG] .github/CODEOWNERS:14 config/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:15 crates/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:16 crates/router/src/types/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:17 crates/router/src/services/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:18 crates/router/src/db/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:19 crates/router/src/routes/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:20 migrations/ @juspay/hyperswitch-framework [CONFIG] .github/CODEOWNERS:21 v2_migrations/ @juspay/hyperswitch-framework

Finding

Does the system provide evidence of documented internal controls over financial reporting, including control objectives, control activities, and monitoring procedures, as required under SOX Section 404(a)?

Remediation

For the critical code paths listed in `.github/CODEOWNERS` (e.g., `crates/router/src/services/` and `crates/router/src/db/`), verify that specific, comprehensive documentation of internal controls over financial reporting, detailing control objectives, activities, and monitoring procedures, exists and is readily accessible. Absence of such explicit documentation for these components risks non-compliance with SOX Section 404(a).

SOX-008 · Possible False Positive

Medium Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence consists solely of configuration files related to CI/CD checksums for codebase integrity, which do not directly demonstrate controls to prevent unauthorized alteration or destruction of financial records as required by SOX Section 802.

Evidence

[CONFIG] .dockerignore:81 .idea/caches/build_file_checksums.ser [CONFIG] .github/workflows/CI-pr.yml:199 checksum: true [CONFIG] .github/workflows/CI-pr.yml:287 checksum: true [CONFIG] .github/workflows/CI-push.yml:100 # checksum: true [CONFIG] .github/workflows/CI-push.yml:110 checksum: true [CONFIG] .github/workflows/CI-push.yml:116 checksum: true [CONFIG] .github/workflows/CI-push.yml:193 # checksum: true [CONFIG] .github/workflows/CI-push.yml:199 checksum: true

Finding

Does the system implement controls to prevent unauthorized alteration or destruction of financial records, including integrity verification, immutable storage, and tamper detection mechanisms, consistent with SOX Section 802 anti-destruction requirements?

Remediation

The `checksum: true` entries in `.github/workflows/CI-pr.yml` and `CI-push.yml` ensure build artifact integrity but do not directly address SOX Section 802 anti-destruction requirements for financial records. To comply, specific data integrity checks, immutable audit trails, or database-level constraints for financial transactions must be implemented within the application or data layer, as the current evidence does not demonstrate direct controls for financial data integrity.

TCPA

FCC · $500-$1,500 per violation

8 findings · 8 possible FP

Possible False Positives (8)Gemini flagged these as likely pattern matches in non-source-code files. Review before acting.

›

TCPA-001 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided, consisting solely of general licensing terms from a `LICENSE` file (e.g., 'agreed to in writing'), is unrelated to obtaining prior express written consent for sending marketing or promotional text messages under TCPA, which requires specific mechanisms for user opt-in for SMS.

Evidence

[CONFIG] LICENSE:136 the terms of any separate license agreement you may have executed [CONFIG] LICENSE:145 agreed to in writing, Licensor provides the Work (and each [CONFIG] LICENSE:157 negligent acts) or agreed to in writing, shall any Contributor be [CONFIG] LICENSE:172 of any other Contributor, and only if You agree to indemnify, [CONFIG] LICENSE:198 Unless required by applicable law or agreed to in writing, software [DOCS] api-reference/essentials/go-live.mdx:11 ### Signing of Hyperswitch services agreement [DOCS] api-reference/essentials/go-live.mdx:13 - [ ] Ensure that the Hyperswitch services agreement is signed and shared with the Hyperswitch team. [CONFIG] config/dashboard.toml:11 agreement_url=""

Finding

Does the system obtain prior express written consent before sending marketing or promotional text messages, including a clear and conspicuous disclosure that consent is being sought, as required under 47 U.S.C. §227(b)(1) and 47 CFR §64.1200(a)(2)?

Remediation

Implement a comprehensive SMS consent management system that captures prior express written consent before sending any marketing or promotional text messages. This should include: clear and conspicuous disclosure language explaining what the user is consenting to, a mechanism to capture and store consent records with timestamps, opt-out instructions in all marketing messages, and validation logic to prevent SMS sending without verified consent. Consider extending the existing agreement framework patterns found in the dashboard metadata to include SMS-specific consent workflows.

TCPA-002 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence, `cancel-in-progress: true` in GitHub Actions workflow configuration files, is an internal CI/CD setting unrelated to user communication or opt-out mechanisms covered by TCPA and CTIA guidelines.

Evidence

[CONFIG] .github/workflows/CI-pr.yml:11 cancel-in-progress: true [CONFIG] .github/workflows/CI-push.yml:14 cancel-in-progress: true [CONFIG] .github/workflows/api-migrations-compatibility.yml:26 cancel-in-progress: true [CONFIG] .github/workflows/archive/connector-sanity-tests.yml:17 cancel-in-progress: true [CONFIG] .github/workflows/archive/connector-ui-sanity-tests.yml:12 cancel-in-progress: true [CONFIG] .github/workflows/cypress-tests-runner.yml:1269 - name: Stop running server [CONFIG] .github/workflows/cypress-tests-runner.yml:14 cancel-in-progress: true [CONFIG] .github/workflows/migration-check.yaml:12 cancel-in-progress: true

Finding

Does the system provide a clear and easy mechanism for recipients to opt out of receiving further messages, and does it honor opt-out requests promptly, as required under TCPA and CTIA guidelines?

Remediation

The `cancel-in-progress: true` setting in `.github/workflows/*.yml` files controls internal CI/CD workflow execution, not user communication opt-out features. No specific changes are required in these configuration files to address TCPA-002, as this setting poses no TCPA compliance risk related to opt-out mechanisms.

TCPA-003 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cites 'NationalRegistryOfLegalEntities' and 'national registry of natural persons in Brazil,' referring to Brazilian identity verification systems (CNPJ/CPF) within financial connectors, which are distinct from the U.S. National Do Not Call Registry for telemarketing compliance under TCPA.

Evidence

[SOURCE] crates/hyperswitch_connectors/src/connectors/ebanx/transformers.rs:80 NationalRegistryOfLegalEntities, [SOURCE] crates/hyperswitch_connectors/src/connectors/ebanx/transformers.rs:120 EbanxDocumentType::NationalRegistryOfLegalEntities [SOURCE] crates/hyperswitch_connectors/src/connectors/facilitapay/requests.rs:86 /// which is the national registry of legal entities in Brazil used as a unique identifier for Brazi [SOURCE] crates/hyperswitch_connectors/src/connectors/facilitapay/requests.rs:90 /// which is the national registry of natural persons in Brazil used as a unique identifier for Braz [DOCS] crates/router/src/utils/user/blocker_emails.txt:739 idncafe.com [CONFIG] crates/router_env/Cargo.toml:32 tracing-subscriber = { version = "0.3.19", default-features = true, features = ["env-filter", "json" [SOURCE] crates/router_env/src/logger/formatter.rs:19 registry::{LookupSpan, SpanRef}, [SOURCE] crates/router_env/src/logger/setup.rs:65 let subscriber = tracing_subscriber::registry()

Finding

Does the system check phone numbers against the National Do Not Call Registry and maintain an internal do-not-call list before initiating outbound calls or messages, as required under 47 CFR §64.1200(c)?

Remediation

Implement Do Not Call Registry integration by adding functionality to check phone numbers against the National Do Not Call Registry before initiating any outbound calls or messages. Create and maintain an internal do-not-call list with appropriate data storage and lookup mechanisms. Add validation logic in the outbound communication pipeline to verify numbers against both the national registry and internal suppression lists before processing calls or SMS messages.

TCPA-004 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The provided evidence from a GitHub workflow configuration comment and payment processing documentation is entirely unrelated to TCPA message frequency disclosure requirements, indicating a severe misinterpretation by the primary analysis tool.

Evidence

[CONFIG] .github/workflows/release-nightly-version-reusable.yml:107 # The 2nd capture group contains the mi [DOCS] add_connector.md:141 - Payment authorization and capture [DOCS] add_connector.md:203 | **Authorization** | Authorize and immediately capture payment | [crates/hyperswitch_int [DOCS] add_connector.md:204 | **Authorization‑Only**| Authorize payment for later capture | [crates/router/src/type [DOCS] add_connector.md:205 | **Capture** | Capture a previously authorized payment | [crates/router/src/type [DOCS] add_connector.md:241 Chooses purchase (auto‑capture) or preauth endpoint in `get_url()` and processes payment data direct [DOCS] add_connector.md:405 settle: item.router_data.request.is_auto_capture()?, [DOCS] add_connector.md:466 | `Authorized` | `AttemptStatus::Authorized` | Payment authorized, awaiting capture |

Finding

Does the system disclose to consumers the expected frequency of messages before obtaining consent, and does it enforce frequency limits consistent with the disclosed rate, as recommended by CTIA guidelines?

Remediation

Implement a consumer consent interface that clearly displays message frequency expectations (e.g., "You will receive up to 5 messages per week") before collecting opt-in consent. Add backend enforcement mechanisms to track and limit message sending based on disclosed frequencies. Create audit trails for consent collection that include timestamp, frequency disclosed, and consumer acceptance. Consider adding configuration management for different message types and their respective frequency limits to ensure compliance with CTIA messaging principles.

TCPA-005 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided (card issuer, device brand, and generic 'branding' in a dashboard configuration) is entirely unrelated to sender identification requirements for outbound messages under TCPA and CTIA regulations.

Evidence

[DOCS] add_connector.md:1000 - `get_card_issuer()` – Returns card brand (Visa, Mastercard, etc.) [CONFIG] api-reference/rust_locker_open_api_spec.yml:314 card_brand: [CONFIG] config/dashboard.toml:17 branding=false [CONFIG] crates/analytics/docs/clickhouse/scripts/authentications.sql:53 `device_brand` Nullable(String), [CONFIG] crates/analytics/docs/clickhouse/scripts/authentications.sql:121 `device_brand` Nullable(String), [CONFIG] crates/analytics/docs/clickhouse/scripts/authentications.sql:191 `device_brand` Nullable(String), [CONFIG] crates/analytics/docs/clickhouse/scripts/authentications.sql:254 device_brand, [SOURCE] crates/analytics/src/auth_events/core.rs:194 AuthEventDimensions::DeviceBrand => fil.device_brand,

Finding

Does the system include proper sender identification in all outbound messages, including the identity of the entity sending the message and how to contact them, consistent with TCPA and CTIA requirements?

Remediation

No remediation is needed for this specific finding as the cited evidence (`add_connector.md`, `api-reference/rust_locker_open_api_spec.yml`, `config/dashboard.toml`, `authentications.sql`) pertains to card issuers, device brands, or internal dashboard branding, none of which constitute TCPA/CTIA sender identification for outbound communications, therefore no regulatory risk from this evidence exists.

TCPA-006 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided refers only to a configuration flag and documentation, not to application source code that would demonstrate the actual implementation of TCPA-specific consent record-keeping details like date, time, method, and specific consent language.

Evidence

[CONFIG] config/dashboard.toml:25 audit_trail=true [DOCS] crates/analytics/docs/README.md:146 audit_trail=true

Finding

Does the system maintain records of consent that would be sufficient to demonstrate compliance in the event of a dispute, including the date, time, method of consent, and the specific consent language presented to the consumer?

Remediation

The `audit_trail=true` setting in `config/dashboard.toml` and its description in `crates/analytics/docs/README.md` must be enhanced to explicitly specify the capture and storage mechanisms for TCPA consent, including date, time, method, and specific consent language, to prevent regulatory fines.

TCPA-007 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence cited consists solely of configuration files (`.dockerignore`, `.github/api-migration-compatibility/.oasdiff-severity-levels.yaml`) which define build exclusions and API deprecation policies, none of which directly or indirectly pertain to the application's handling of consumer consent revocation for TCPA purposes.

Evidence

[CONFIG] .dockerignore:136 # .nfs files are created when an open file is removed but is still being accessed [CONFIG] .dockerignore:178 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries [CONFIG] .github/api-migration-compatibility/.oasdiff-severity-levels.yaml:1 api-path-removed-without-deprecation: ERR [CONFIG] .github/api-migration-compatibility/.oasdiff-severity-levels.yaml:2 api-path-removed-before-sunset: ERR [CONFIG] .github/api-migration-compatibility/.oasdiff-severity-levels.yaml:3 api-removed-without-deprecation: ERR [CONFIG] .github/api-migration-compatibility/.oasdiff-severity-levels.yaml:4 api-removed-before-sunset: ERR [CONFIG] .github/api-migration-compatibility/.oasdiff-severity-levels.yaml:5 api-operation-id-removed: ERR [CONFIG] .github/api-migration-compatibility/.oasdiff-severity-levels.yaml:6 api-tag-removed: WARN

Finding

Does the system honor revocation of consent through any reasonable means indicated by the consumer, not limited to specific keywords, and process revocation within a reasonable timeframe, consistent with FCC guidance?

Remediation

The listed `.dockerignore` and `.github/api-migration-compatibility/.oasdiff-severity-levels.yaml` files pertain to build rules and API versioning, not customer consent revocation logic. Modifying these configuration files would not address TCPA consent handling requirements, as the provided evidence is irrelevant to the claimed risk.

TCPA-008 · Possible False Positive

High Risk›

Regulatory Standard

Gemini Verification

POSSIBLE FALSE POSITIVE

The evidence provided exclusively cites configuration files and CI/CD workflow definitions, not application source code directly responsible for sending outbound communications or implementing time-of-day restrictions, thus making a direct compliance risk from this evidence uncertain.

Evidence

[CONFIG] .github/CODEOWNERS:150 crates/router/src/scheduler/ @juspay/hyperswitch-process-tracker [CONFIG] .github/workflows/archive/connector-sanity-tests.yml:8 schedule: [CONFIG] .github/workflows/release-nightly-version.yml:4 schedule: [CONFIG] Dockerfile:57 # 2. BINARY=scheduler, SCHEDULER_FLOW=consumer - part of process tracker [CONFIG] Dockerfile:58 # 3. BINARY=scheduler, SCHEDULER_FLOW=producer - part of process tracker [CONFIG] Dockerfile:60 ARG SCHEDULER_FLOW=consumer [CONFIG] Dockerfile:70 SCHEDULER_FLOW=${SCHEDULER_FLOW} \ [DOCS] README.md:113 - **Full**: Includes monitoring + schedulers

Finding

Does the system enforce time-of-day restrictions for outbound calls and messages, ensuring they are not sent before 8:00 AM or after 9:00 PM in the recipient's local time zone, as required under 47 CFR §64.1200(c)(1)?

Remediation

The `crates/router/src/scheduler/` (as indicated in `.github/CODEOWNERS:150` and `Dockerfile:57-58` for the `scheduler` binary) must incorporate logic to validate recipient local time zones, preventing any outbound calls or messages from being sent before 8:00 AM or after 9:00 PM to avoid violations of 47 CFR §64.1200(c)(1).

What This Analysis Covers

OpenDocket scans source code patterns — specifically whether code handles regulated data in compliance-aware ways. It searches for evidence of encryption, access controls, consent mechanisms, audit logging, and other patterns that regulators look for.

What It Does Not Cover

Only public repository content is analyzed
Files in .gitignore are not scanned
Infrastructure, deployment, and cloud configuration are outside scope
Operational policies and procedures are outside scope
This analysis covers code at time of scan — changes after scan date are not reflected

Legal Limitations

This report is not defensible in court
It does not constitute legal advice
It does not satisfy regulatory audit requirements
To obtain a defensible compliance assessment, engage a licensed compliance attorney and certified auditor
OpenDocket provides directional guidance only

How Findings Are Generated

Primary analysis by Claude Sonnet (Anthropic)
Verification by Gemini 2.5 Flash (Google)
Question libraries are open source and community-maintained
All questions cite regulatory source text
Questions have not been validated by a licensed attorney

Why Two Models?

Claude Sonnet scans broadly — it finds every pattern that could indicate a compliance risk. This produces a comprehensive set of findings but includes noise from documentation files, config references, and test data.

Gemini 2.5 Flash then challenges each finding independently. It asks: is this evidence from actual application code? Would a regulator actually find this concerning? Is the severity appropriate?

The result is a tiered output:

CONFIRMED — Gemini agrees this is a real risk
CONTEXT DEPENDENT — Risk depends on deployment/infrastructure
POSSIBLE FALSE POSITIVE — Likely noise, review before acting

The confirmed count is the number you should act on. The total count shows the full scope of what was examined.

Evidence Tiers

Evidence is classified into three tiers based on file type:

[SOURCE] — Application source code (.ts, .py, .go, .rs, etc.) — strongest evidence
[CONFIG] — Configuration files (.yml, .json, .toml, Dockerfile) — moderate evidence
[DOCS] — Documentation (.md, .txt, .html) — context only, cannot produce High Risk findings

A finding is only classified as High Risk if supported by at least two source code files with matching evidence. Documentation references alone produce Pattern of Concern at most.

How to Use This Report

Share with your engineering lead for remediation planning
Share with your attorney as a starting point for compliance review
Re-scan after remediation to track progress
Do not present this as proof of compliance

Findings based on OpenDocket's open source question libraries. View and contribute