Security & Data Policy

Effective: April 20, 2026

1. Introduction

This document describes Plumb Software Inc.’s information security, data security, and data retention practices. It satisfies the requirements set forth by our payment processors and applies to all customer data processed by Plumb, our employees, and the sub-processors listed in the Privacy Policy.

Plumb’s production infrastructure is cloud-hosted using established third-party providers that maintain their own independent security attestations (e.g., SOC 2, ISO 27001). A complete list of Plumb’s sub-processors, including infrastructure providers, is published in the Privacy Policy §6.5.

Plumb continuously improves its security program and will update this document as its practices evolve.

Effective date: April 20, 2026.

2. Information Security Policy

2.1 Employee Access Controls for Customer Data

Access to customer data by Plumb employees and contractors is governed by the following controls:

• Role-based access (RBAC): Access to production systems is granted by role. Each role is defined with the minimum set of permissions required to perform the job function.
• Principle of least privilege: Employees are granted only the access strictly necessary for their current responsibilities.
• Multi-factor authentication: Plumb requires multi-factor authentication for employee access to every production console and administrative dashboard that supports it.
• Access reviews: Access grants are reviewed when an employee or contractor’s role changes and when their engagement with Plumb ends. Access is revoked promptly on departure.
• Audit logging: Administrative access to customer data in production is logged by the underlying infrastructure and payment-processor platforms.

2.2 Authentication and Session Management

End-user authentication is handled by a managed identity provider. Plumb verifies each incoming request against the identity provider’s current public keys on a per-request basis and does not cache or trust tokens that have been revoked.

• Password policy: Password policy is enforced by Plumb’s identity provider and includes minimum length and character-class requirements (consistent with guidance in NIST Special Publication 800-63B), together with protections against credential changes without prior account verification.
• Session lifetime: Access tokens are short-lived and are refreshed automatically by the identity provider. Plumb’s backend validates each incoming token against the identity provider’s current public keys on every request, so revoked or rotated keys take effect immediately.
• Account recovery: Account recovery flows rely on verified email addresses and are rate-limited by the identity provider.

2.3 Data Encryption

• In transit: All client-server communication is protected by TLS 1.2 or later, with HSTS enabled on Plumb’s production domains.
• At rest: Database storage is encrypted at rest using AES-256 volume-level encryption managed by the hosting provider. Application files and artifacts stored in object storage are encrypted at rest by the underlying storage provider.
• Bank account data (ACH): Full bank account numbers and routing numbers are not stored in Plumb’s primary application data. These are held directly by Straddle Payments, Inc under its published Data Security Measures, which include AES-256 field-level encryption of payment and banking account data stored in a separate secured data vault.
• Payment card data: Full payment card numbers are not stored in Plumb’s primary application data. These are held directly by Stripe in compliance with PCI-DSS standards and Stripe’s encryption and key-management practices.
• Tokenization: Plumb stores only masked or tokenized identifiers returned by its payment processors (for example, last four digits, processor reference tokens, and Straddle paykeys) rather than full account or card numbers. Tokens are designed to have no extrinsic or exploitable meaning outside the payment processor’s systems. Raw webhook payloads received from the payment processors are persisted for reconciliation and audit purposes and contain only masked or tokenized identifiers, never full account or card numbers.
• Key management: Encryption keys for hosted databases, object storage, and edge infrastructure are managed by the respective hosting providers’ key-management systems. Key rotation follows each provider’s default schedule.

2.4 Incident Response

Plumb maintains an incident response process to detect, contain, and recover from security incidents that affect customer data.

• Incident owner: Plumb designates a senior member of the team as incident response owner and decision-maker on customer notification.
• Severity classification: Incidents are classified by impact. A confirmed unauthorized access to customer data is escalated immediately, while suspected-but-unconfirmed events trigger an internal investigation first.
• Customer notification: For confirmed incidents involving unauthorized access to or disclosure of customer personal information, Plumb will notify affected customers as promptly as practicable and in any event within seventy-two (72) hours of confirming the incident, unless a shorter period is required by applicable law.
• Payment-processor incidents: Under the Data Processing Agreement between Plumb and Straddle Payments, Inc, Straddle will notify Plumb within seventy-two (72) hours of discovering an incident affecting Plumb’s customer data. Plumb will forward any such notification to affected customers within seventy-two (72) hours of Plumb’s receipt, along with any additional information Plumb is able to provide.
• Post-incident review: Every confirmed incident is followed by a written post-mortem with documented action items.
• Reporting an incident to Plumb: Security incidents may be reported to security@buildwithplumb.com.

2.5 Vulnerability Management

• Dependency scanning: Plumb uses automated dependency vulnerability scanning across its code repositories. The scanner surfaces known vulnerabilities in third-party dependencies and can automatically open pull requests to apply available security patches.
• Time-to-patch targets: Critical vulnerabilities are prioritized for immediate patching. Other severities are addressed within a documented cadence consistent with industry norms.

2.6 Logging and Monitoring

• Application logs: The Plumb backend emits structured JSON logs and ships them to a centralized log-management service. Plumb’s hosting providers also maintain their own operational log surfaces.
• Log retention: Logs are retained according to the default retention policies of Plumb’s hosting and log-management providers.
• Personally identifiable information in logs: Plumb’s logging convention is to avoid writing personally identifiable information to application logs.
• Access to logs: Log access is limited to engineering personnel who require it for debugging and incident response.

2.7 Secure Software Development Lifecycle

• Code review: All production changes go through a pull request to a protected production branch; direct pushes are prohibited. Required CI status checks must pass before any merge.
• Branch protection: Plumb’s production branches are additionally protected against force pushes and branch deletions.
• Required CI checks: Plumb’s application repositories require lint, type checks, and tests to pass on every pull request before merge. CI coverage across all repositories is continuously expanded as the program matures.
• Deployment: Deployments to production are automated from the protected production branch, not from individual developers’ workstations.

2.8 Physical Security

All Plumb production infrastructure is cloud-hosted. Plumb does not operate any physical data centers or office-based servers. Physical security of the underlying data centers is maintained by Plumb’s hosting providers under their own independent security attestations (e.g., SOC 2, ISO 27001).

2.9 Third-Party Service Provider Management

• The complete list of Plumb’s sub-processors and the data categories they process is published in the Privacy Policy §6.5.
• Sub-processors are evaluated for security posture before engagement. Where required by law, a data processing agreement is in place before customer data is shared with a sub-processor.
• Material changes to a sub-processor’s security posture are tracked through the sub-processor’s own security-advisory channels.

3. Data Security Policy

This section complements §2 with controls that are specifically about the security of customer data in transit and at rest, data classification, and backup/disaster recovery.

3.1 Network Security

• All application traffic is served over HTTPS with TLS 1.2 or later.
• Authenticated API endpoints are protected by authentication middleware that verifies a provider-issued JWT on every request.
• Database access: Plumb’s primary database is hosted by a managed cloud database provider and is accessed only through authenticated application-layer connections. It is not exposed as an unauthenticated public endpoint, and direct database access from end-user sessions is not permitted — all database queries flow through the Plumb backend, which authenticates the caller and enforces row-level access controls.
• Edge-level protections (DDoS mitigation, rate limiting, bot protection) are provided by the hosting provider’s global edge network.

3.2 Data Classification

Plumb classifies the data it handles into the following categories:

• Customer personal information: Name, email address, phone number, business address, role.
• Customer financial data: Masked bank account information (last 4 digits, bank name, opaque processor reference), masked payment card information. Full bank routing/account numbers and payment card numbers are held by Plumb’s payment processors, not by Plumb itself.
• Project and business data: Work orders, contracts, budgets, payment schedules, milestones, project documents.
• Authentication data: Password hashes and multi-factor secrets are managed by Plumb’s identity provider; Plumb does not store passwords in its own database.
• Operational data: Application logs, performance metrics, and request traces. Plumb’s logging convention is to avoid writing personally identifiable information to these streams; see §2.6 for details.

3.3 Backup and Disaster Recovery

• Database backups: Plumb’s production database runs on a hosted tier that includes automated daily backups.
• Backup retention: Backup copies are retained consistent with the active retention periods in §4 plus a rolling operational window. Backups do not extend retention beyond the periods defined in §4 for the purposes of record-keeping.
• Recovery capability: In the event of a major outage or corruption, Plumb relies on its hosting providers’ built-in backup-restore and failover capabilities to recover the application and database layers. Plumb’s recovery procedures are continuously refined as the program matures.

3.4 Regular Security Assessments

• Code review: Every production change is reviewed before merge.
• Dependency scanning: Continuous via the automated scanner described in §2.5.
• Static analysis: Language-specific static analysis tools are run as part of the continuous integration pipeline before merge to protected branches.
• Security architecture review: Major new features touching authentication, authorization, payments, or customer data are reviewed for security implications before implementation.

4. Data Retention Policy

This section is the source of truth for how long Plumb keeps each category of customer data. It is identical to the retention schedule in the Privacy Policy §8; if the two pages ever disagree, the Privacy Policy controls.

4.1 Retention Periods by Data Category

• ACH authorization records: at least two (2) years after the final transaction (Nacha requirement).
• Transaction records (payments, transfers, status history): at least two (2) years after the final transaction (Nacha requirement).
• Revocation requests: at least two (2) years after revocation (Nacha requirement).
• Account and user records: lifetime of the account plus one (1) year after account closure.
• Project and work order data: lifetime of the account plus one (1) year.
• Support tickets and communications: three (3) years.
• Application logs (no personally identifiable information): retained according to the default retention policies of Plumb’s hosting and log-management providers.
• Authentication and security events: retained by Plumb’s identity provider per its account retention policy.

4.2 Deletion Procedures

• Backup lifecycle: Backup copies are not retained longer than necessary to support operational recovery, and are eligible for legal holds where applicable.
• On-demand deletion: Individual data subject requests are handled by the privacy contact (see §5). Deletion of payment-related data may be delayed as described in the Privacy Policy §9.4 while Plumb coordinates with its payment processors to satisfy regulatory retention requirements.

4.3 Legal Hold Exception

Records that become subject to a legal hold — whether due to an actual or reasonably anticipated legal, regulatory, or contractual obligation — are exempt from deletion until the hold is lifted. Plumb will apply a legal hold in response to a specific obligation and will document the scope and duration of the hold internally.

4.4 Audit Log Reproducibility

When Plumb captures an ACH authorization from a payer, the record includes:

• The exact text the payer agreed to at the time of authorization.
• The version of the Terms of Service in effect at the time of authorization, resolvable by version slug against the Legal Archive.
• Captured metadata, including timestamp, IP address, user agent, and authenticated user identity at the time of consent.

Plumb can reproduce any captured ACH authorization in its original form on request. Requests to reproduce a specific ACH authorization record may be sent to legal@buildwithplumb.com and will be processed within the timeframe set by Nacha Operating Rules and applicable law.

5. Contact Information