Security

MERGEguard interacts directly with client contact data inside Clio. The system is designed to minimize risk by limiting when data is written, isolating tenant data, and requiring explicit user intent before any destructive action.

This page outlines the controls in place across application logic, authentication, storage, and infrastructure.

Read-only by default

All scan operations are read-only.

MERGEguard retrieves contact data from Clio, analyzes it for duplication patterns, and stores results for review. No writes occur during scanning.

The first write to Clio only occurs when a user explicitly selects records and confirms Process merges.

Controlled write model

MERGEguard does not perform automatic merges. Every write to Clio traces to a single explicit user confirmation.

Each merge requires:

• •Selection of a keeper record
• •Explicit selection of merge candidates
• •Final confirmation before execution

After that confirmation, the merge itself runs as a background job that may continue after your browser is closed; large merges are processed in stages, and a stalled job may be resumed automatically. No writes occur without that originating confirmation. Scheduled tasks such as scans and health checks never modify Clio data.

What a merge writes

When you confirm a merge, MERGEguard makes these changes in Clio, and only these:

• •Updates the keeper contact’s fields with information carried from the duplicate (email addresses, phone numbers, addresses, custom fields)
• •Re-points matter references from the duplicate to the keeper: the matter client, contact-type custom fields, bill-recipient roles, and split-invoice payer roles (existing percentages preserved)
• •Re-points the duplicate’s communications, notes, documents, and relationships to the keeper
• •Deletes the duplicate contact as the final step, only after the moves above succeed

MERGEguard never creates, modifies, or deletes invoices, balances, payments, time entries, or trust accounting, and it does not write to any system outside Clio. Billing-routing changes are limited to carrying the deleted contact’s existing roles onto the keeper so invoices continue reaching the right party.

Pre-merge snapshot system

Before a duplicate is deleted, MERGEguard captures a snapshot of the record being merged.

Snapshot scope includes:

• •Contact fields
• •Notes
• •Communications
• •Documents
• •Custom fields
• •Relationships

Snapshots are captured on a best-effort basis: if part of a record cannot be read at merge time, the snapshot records what was available rather than blocking the merge. Snapshots are stored separately from active records, retained for the life of your account, and deleted with the rest of your data roughly 90 days after your engagement ends.

If a merge outcome needs review, the snapshot supports manual re-creation of the removed record’s core data. It is an audit record, not a byte-complete backup.

Audit logging

MERGEguard maintains an audit trail for merge activity.

Each merge records:

• •Acting user
• •Timestamp
• •Keeper record
• •Merged records
• •Outcome status (success or failure)

Audit data is retained independently from application logs and is designed to support review and reconstruction of actions taken.

Authentication and session security

• •Passkeys (WebAuthn) are the default authentication method
• •Optional MFA methods: TOTP, SMS, or email OTP
• •Passwords are hashed with bcrypt (cost factor 12)

Session controls:

• •httpOnly cookies
• •Secure flag in production
• •SameSite=Lax
• •Session rotation after MFA verification

Protection mechanisms:

• •Login attempts are rate-limited per account and per IP
• •Repeated failures trigger a Cloudflare Turnstile challenge

Merge authorization

Merge execution requires recent second-factor verification.

A valid session alone is not sufficient to perform destructive actions.

Clio OAuth token handling

Clio access and refresh tokens are encrypted at rest at all times. Established connections keep tokens in Supabase Vault; tokens written at firm creation are first stored AES-256-GCM encrypted in the database and migrate into Vault on next use.

• •Encrypted at rest using pgsodium-backed key management
• •Encryption keys are not stored alongside application data
• •Tokens are never exposed to the client or stored in plaintext

Vault access is restricted to server-side service-role execution.

When Clio is disconnected, associated vault entries are permanently deleted.

Data isolation and access control

MERGEguard is a multi-tenant system. Tenant isolation is enforced in the application layer: every query is scoped to the authenticated firm.

• •Every record is scoped by firm_id
• •All queries enforce firm-level filtering
• •Row-level security (RLS) is enabled on all tables as a deny-by-default backstop; it is not the isolation mechanism
• •Server-side operations use a service-role key not exposed to the client

All database access is server-side. There is no client-side database access path.

Infrastructure and hosting

• •Application hosted on Vercel (US region)
• •Database hosted on Supabase Postgres (US region)
• •All traffic encrypted via HTTPS (TLS 1.2+)

Operational controls:

• •Daily automated backups with 7-day retention
• •Environment variables used for secret management
• •No secrets stored in source code or client bundles

Sub-processors

Each sub-processor handles a specific portion of the service. All are US-based and operate under their own security commitments.

Each vendor is governed by their own DPA and operates under their published security commitments.

Data residency

MERGEguard processes and stores all data in the United States. We do not currently offer international data residency, and the service is not available to customers outside the United States.

Logging and observability

MERGEguard records operational events for debugging and system health.

To reduce exposure:

• •IP addresses and email addresses are hashed using salted SHA-256
• •Logs are structured to avoid storing raw identifiers

User-facing errors do not expose internal system details. Detailed diagnostics are retained internally.

Failure handling and data safety

MERGEguard is designed to fail safely.

• •If a reference move or billing carry fails, the duplicate contact is not deleted
• •If any step of a merge fails, the operation stops before partial data loss
• •No destructive action proceeds without required preconditions

This prevents incomplete merges and reduces the risk of inconsistent data states.

Incident response

MERGEguard maintains an incident response process to detect, contain, and communicate security events. In the event of a breach affecting customer data, we will notify affected customers within 72 hours of confirming the incident. Each notification includes a point of contact, a preliminary technical analysis of the incident, and a remediation plan with reasonable timelines. Internal security events are triaged and remediated against severity. Vulnerability reports received via security@mergeguard.net are acknowledged within one business day.

Webhook security

Incoming webhooks are verified before processing.

• •Stripe events are validated using signature verification
• •Requests that fail verification are rejected before any logic runs

Rate limiting and abuse protection

• •Login attempts are rate-limited per account and per IP
• •OTP requests are throttled per user and per IP
• •Scan execution is limited to one active job per firm

Additional limits may be introduced as usage scales.

Data usage and privacy

MERGEguard does not use customer data for:

• •Advertising
• •Marketing analytics
• •Model training
• •Resale or third-party sharing

Data is used strictly to operate the service.

What MERGEguard does not do

• •No automatic merges
• •No writes to Clio without your explicit confirmation
• •No access outside your firm’s data scope
• •No silent changes to Clio records

All data changes are explicit and user-initiated.

Customer testing

Customers may request to assess the security of MERGEguard. To arrange scope and timing, contact security@mergeguard.net.

• •Testing is coordinated in advance with our team
• •We do not currently operate a separate staging environment; this is disclosed in our security package
• •Test scope, timing, and environment are agreed case by case so production customers are never impacted

Compliance and certifications

MERGEguard does not currently maintain SOC 2 or ISO 27001 certification.

Security practices are implemented directly in the system architecture.

MERGEguard is designed against the Minimum Viable Secure Product (MVSP) baseline. Gap analysis available on request to security@mergeguard.net.

Security philosophy

No system is perfectly secure.

MERGEguard is designed to:

• •Minimize write operations
• •Require explicit user intent
• •Isolate tenant data
• •Limit exposure of sensitive data
• •Fail safely when conditions are not met
• •Maintain auditability of actions

Reporting a vulnerability

Security issues can be reported to:

security@mergeguard.net

Reports are acknowledged within one business day.

Please do not disclose vulnerabilities publicly.