Security

1. Overview

Customers place other companies’ insurance documents and business contact details in WatchMyCover. This page describes the administrative and technical safeguards we maintain to protect that information. It describes the system as it operates today. Where a measure is planned and not yet in place, this page says so.

This page is provided for information. Our contractual security commitments are set out in the Terms of Service and the Data Processing Addendum.

2. Certifications and independent testing

WatchMyCover has not obtained a SOC 2 report or an ISO/IEC 27001 certification, and no independent third-party penetration test has been performed. We conduct our own security reviews and remediate what they find. If your procurement process requires a certification, we do not currently have one to provide, and we will complete a reasonable security questionnaire on request.

3. Hosting and data location

The Services run on infrastructure operated by established cloud providers in the United States, which are identified in our Privacy Policy. We do not operate our own data centers. Customer data, including uploaded documents, is stored in the United States.

4. Encryption

All connections to the Services are encrypted in transit using Transport Layer Security, and browsers are instructed to use encrypted connections only. Stored data, including the database and uploaded documents, is held with a provider that encrypts it at rest.

Passwords are stored only as salted hashes produced by a memory-hard function and are never stored or logged in readable form. A new password is checked against a database of passwords exposed in known data breaches, and is refused if it appears there; that check discloses only the first five characters of a hash of the password, never the password itself.

5. Separation of customers

Every request is scoped to the organization of the signed-in user, which is read from the database on each request. A read includes the organization in the query itself, so that another customer’s record cannot match; a write first confirms that the record belongs to the caller’s organization. Automated tests assert that attempts to read, change, archive, or export another customer’s records are refused.

6. Authentication and sessions

• A new account must confirm its email address through a link before it can use the application, so that no one can cause email to be sent in the name of a company they do not control.
• Any user may enable two-factor sign-in with an authenticator application, with ten single-use backup codes. Five incorrect codes lock the account for fifteen minutes. The owner of an account may require two-factor sign-in for every member of the team. Our own operations console cannot be used without it.
• Session cookies are inaccessible to scripts, are sent only over encrypted connections in production, and are restricted to same-site requests.
• A user’s authorization is read from the database on every request and is not trusted from the session, so that removing a person’s access takes effect immediately.
• A password reset link can be used once, expires after one hour, and ends every other session on the account.

7. Certificate documents

Uploaded documents are held in private storage. There are no public addresses for them and no pre-signed links. Every request for a document passes through our application, is authorized against the caller’s organization at that moment, and is recorded.

Only PDF, PNG, and JPEG files are accepted, and the type of each file is determined from its contents and not from its name. Our servers deliver a document only as a file download and never as a page of our site. The preview shown in the application is drawn by the application itself from the file’s contents, without running any script the file may contain.

8. Links that grant access

Upload links, shared report links, and invitations are generated from 32 bytes of random data, and only a hash of each is stored. An upload link accepts a file. It shows its holder the customer’s name, logo, and postal address, what that customer requires of that one subcontractor, and what is short on that subcontractor’s own record, and after a file is sent it gives a first reading of what still appears short. It shows no other subcontractor and no stored document, and it gives no way to list anything. Any link can be withdrawn individually, and archiving a subcontractor withdraws all of that subcontractor’s links. A shared report link expires after a period the customer chooses, of up to one year. Upload links and report links stop working if the customer’s account is canceled.

9. Audit records

The Services record changes to subcontractors, certificates, requirement templates, projects, team membership, shared links, and reminder settings, together with sign-ins, password changes and resets, changes to two-factor sign-in, the viewing and downloading of documents, and exports of the register. Each subcontractor’s page shows its own history and every compliance verdict it has received, and owners and administrators can review the record for the whole organization in the application.

10. Application safeguards

• Rate limits: sign-in, registration, and password reset are limited to 8 requests a minute; reads to 120; writes to 40; exports, imports, and full re-checks to 10; and the contact form to 5 an hour. The counters are held in the database, so the limits hold however many servers are running.
• Input validation: every request is parsed against a schema that discards fields it does not expect. Administrative privileges cannot be set through any request. Requests are limited to 256 KB, imports to 4 MB, and uploaded files to 10 MB, with a storage ceiling for each account.
• Browser protections: pages that handle a session or an access link run only scripts that carry a value generated for that request. Our pages cannot be framed by other sites, and redirects after sign-in are accepted only to addresses on our own site.
• Exports: any cell in an exported register that a spreadsheet could interpret as a formula is neutralized before export.
• Payment data: a card is entered on our payment processor’s own page, and the full card number and security code never reach our systems. The billing page shows the card’s network, last four digits, and expiry date as the processor reports them, and we do not store them. Notices from the payment processor and from our email provider are accepted only when their signatures verify.

11. Logging and error handling

Unexpected errors are returned to the browser as a generic message with a reference number and no internal detail. Application logs redact credentials, cookies, secrets, and the tokens contained in upload, report, invitation, reset, and confirmation links. Error reports and product analytics contain route patterns, internal identifiers, counts, and statuses only, and never a name, an email address, a certificate value, or the contents of a document.

12. Software dependencies

Third-party software components are reviewed for published vulnerabilities before each release. As of 02-Oct-2026, that review reported no known vulnerabilities in any component of the Services.

13. Access by our personnel

Access to customer data by our personnel is limited to what is needed to support a customer at its request, to investigate a fault, or to maintain the security of the Services. Our operations console requires two-factor sign-in.

14. Security incidents

If we become aware of a breach of our security that affects a customer’s data, we will notify that customer without undue delay and in any event within 72 hours, as set out in the Data Processing Addendum, and will provide the information the customer needs to meet its own obligations under applicable breach notification laws.

15. Known limitations

We believe a security statement is credible only if it also states what is not in place. The following are current limitations:

• Two-factor sign-in is optional unless the owner of an account requires it for the team. We do not require it of every account.
• Roles are broad. Any member can import subcontractors, archive them, create requirement templates, and export the register. Only owners and administrators can edit or delete templates, manage the team and shared links, and change settings. Finer-grained roles are planned.
• The style policy of our pages permits inline styles, which the interface components require. A style cannot execute code.
• Read state for notifications and for received documents is shared by the organization and is not tracked separately for each user.

16. Reporting a vulnerability

If you believe you have found a security vulnerability in the Services, please report it to info@watchmycover.com with enough detail to reproduce it. We will acknowledge your report, investigate it, and tell you the outcome.

We will not pursue legal action against, or ask law enforcement to investigate, anyone who reports a vulnerability in good faith, makes a reasonable effort to avoid accessing or altering data that is not their own, does not degrade the Services for others, and gives us a reasonable time to remedy the issue before disclosing it. We do not operate a paid bug bounty program.