Security

This page describes how TracePrep Inc., a Texas corporation, protects the systems behind traceprep.com and the TracePrep product application. Written notice may be sent to TracePrep Inc., 214 S Main St Ste 101-C, Duncanville, TX 75116. It describes the systems as they are built today. It is not a warranty, and it is not a certification.

We would rather tell you plainly what we do not have than imply we have it. Section 6 is that list.

1. The marketing site

• traceprep.com is served over HTTPS only. Plain HTTP is redirected.
• The site holds no tax data, no client data, and no Study data. The only personal information it handles is what you choose to submit through its forms (your work email, your firm's size if you give it, and on the Contact page your name and message) and, if you came from a campaign link, the campaign parameters in that link.
• Our own analytics set no cookies, write nothing to browser storage, build no profile, and record no session. See the Privacy Notice.
• The site's forms post to two server-side endpoints, one for email capture and one for the Contact page. Credentials for the email service live only on the server and are never exposed to the browser. A malformed submission is rejected before any third party is contacted, and error logs record a status and a reason, never the address, the key, or the auth header.
• Content is published through a scoped publishing token, not an administrator account. The token can be rotated without a redeploy, and nothing writes the content database except the content platform itself.
• Secrets are held as environment variables in the hosting platform and in a secrets manager. They are not committed to the repository.
• The content database runs on a tier with daily snapshots. Media is stored in a private object store.

2. The product application

The TracePrep application, where firms build Studies, is a separate system from the marketing site with its own controls.

• Identity and access. Accounts, organizations, and memberships are handled by a dedicated identity provider. Access to a Firm's Studies is scoped to that Firm.
• Roles. The Preparer and the Reviewer are distinct roles. Only a Reviewer can sign off on a Study. The platform enforces that separation rather than relying on convention.
• Audit log. Every material action on a Study is recorded to an append-only, tamper-evident audit log. Entries are integrity-chained, and a full verification of each chain runs on a production schedule. For any finalized Study, the log answers who prepared it, who changed what and when, and who approved it.
• Immutability. Finalized artifacts cannot be edited. A correction produces a new version; it does not overwrite the record.
• Evidence integrity. Every figure in a Study traces to its source, occupation, geography, period, and transformation, at field level. The evidence manifest is immutable.
• Storage and durability. Study data is held in a managed Postgres database with point-in-time recovery. Study artifacts are held in a managed object store, with a synchronous backup copy in Amazon S3 (us-east-1). All processing is in the United States. Long-running work runs through a durable execution service. The application runs on a managed hosting platform.
• Retention. After a subscription ends, finalized work stays downloadable for three years, then may be deleted.
• Deletion. Before that window closes, finalized artifacts are destroyed only through an explicit Firm-Admin-initiated process, which is logged and offers an export first. Deletion covers every stored artifact belonging to the Study. Copies held in an immutable or point-in-time-recovery source that cannot be selectively changed stay marked for deletion until that copy expires or is verifiably unreadable. The metadata-only audit chain and a deletion tombstone survive so the chain can still be verified.
• Export. A Firm Admin can export the Firm's Finalized, Delivered, and Superseded Studies at any time during the subscription and throughout the three-year window after it ends. Export is never gated on account or billing state.

3. Data in transit and at rest

Traffic to and from our systems runs over TLS. Data at rest is encrypted by the managed database, object store, and hosting providers we use, under their standard configurations.

4. Vendors

We use a small set of named vendors, listed in the Privacy Notice for the marketing site and in the Product Application Privacy Addendum for the application, published when the application is released. Adding a vendor that handles personal information or Study data is a material change and is published at least 30 days before it takes effect.

5. Reporting a vulnerability

If you believe you have found a security issue, tell us before you tell anyone else. Send it through the Contact page or to [email protected], with enough detail to reproduce it.

We will acknowledge a report within 3 business days and tell you what we plan to do about it.

We will not pursue a claim against a researcher who reports in good faith, stays within their own test data, does not access, alter, or destroy anyone else's data, does not degrade the service, and gives us a reasonable window to fix the issue before disclosing it. We do not currently run a paid bug bounty.

6. What we do not have yet

Stated plainly, so nobody infers it:

• No SOC 2, ISO 27001, or other third-party security certification. We have not completed an audit and do not claim one.
• No third-party penetration test has been performed to date.
• No published uptime commitment or SLA for the marketing site.
• No signed data processing agreement template is published yet. A firm that needs one should ask through the Contact page. Commissioning one with counsel is on our backlog.
• No formal incident-response runbook has been published externally.
• No cyber-liability insurance is bound yet. Buying it, with limits at or above the Security Claims ceiling in the Product Application Terms, is on our backlog ahead of the first paying firm.

If any of this changes, this page changes with it, as a new version.

7. Security incidents

If we become aware of a security incident affecting your Firm's Study data, we will investigate promptly and notify your Firm immediately after discovering the breach.

We hold data your Firm owns, which puts us under Tex. Bus. & Com. Code §521.053(c): a person maintaining sensitive personal information it does not own must notify the owner immediately. The 60-day deadline in §521.053(b) is the owner's deadline for notifying affected individuals, and it belongs to your Firm, not to us. We do not claim it.

Where no statute reaches an incident, we still notify within five business days of determining it occurred. Where a stricter period applies under another law, that period controls.

We do not promise a self-set 72-hour clock. In a real incident the clock starts before anyone knows what happened, and a number we invented would be looser than the one the law already gives you.

8. Changes

This page is versioned. Each version is published at /legal/versions/<version>/security and stays available there.