Data Retention and Deletion Policy

Purpose and scope

This policy is the standard retention schedule referred to in our Privacy Policy, and it implements the data export and deletion commitments in our Terms of Service. It covers the SitewideOps production service (app.sitewideops.com and the mobile field app), the marketing site (sitewideops.com), and the third-party service providers we use to run them.

SitewideOps is a business-to-business service. Each subscribing contractor (“Customer”) controls the records in its own workspace (“Customer Data”). SitewideOps processes Customer Data on the Customer’s behalf and applies this schedule to it.

Retention schedule

Customer Data

Kept for: the life of the subscription. This covers every workspace record: projects, work orders, schedules, employees and crews, customers and vendors, financial documents, time entries, photos and attachments, and the workspace audit trail.

Then: when a subscription ends, the data stays available for export for a 60-day wind-down period. It is deleted or de-identified within 30 days after that window closes, or sooner on a verified request.

Bank and card transaction data imported through Plaid

Kept for: the same schedule as Customer Data.

Then: disconnecting a bank connection revokes the bank access token at Plaid before the stored copy is deleted. If Plaid does not confirm the revocation, the connection is marked Disconnected with the reason and the revocation is retried; a token is never silently left behind. A connection the bank itself revokes is marked Disconnected, and its dead token is discarded when the Customer disconnects it. Resetting or purging a workspace revokes every bank connection first and does not proceed if any revocation fails. Previously imported transactions are deleted on the Customer’s request.

Integration credentials

Kept for: the life of the connection. This covers the access tokens and connection secrets for QuickBooks Online, Sage Intacct, Plaid and similar connections, which are encrypted at rest while we hold them.

Then: they are discarded when the connection is disconnected, and purged with the workspace.

Demo and trial workspaces

Kept for: the length of the evaluation. These workspaces hold fabricated sample data plus whatever the person evaluating types in.

Then: they may be reset or purged at any time after the evaluation ends.

Account, contact and billing records

Kept for: up to 7 years after the business relationship ends. This covers subscriber identity, invoices, payment history and signed agreements, kept for tax, accounting and legal-defense purposes.

Then: they are deleted.

Technical logs

Kept for: a rolling period of no more than 90 days. This covers server request logs, error logs, and email and SMS delivery events.

Then: they age out automatically. They are never used for advertising or profiling.

Database backups

Kept for: the hosting provider’s rolling backup period, currently daily backups kept for 7 days, and never more than 35 days.

Then: data deleted from production ages out of the backups as they rotate. Backups are used only for disaster recovery, never to bring deleted records back for any other purpose.

Mobile crash and error reports

Kept for: no more than 90 days. When the mobile field app crashes, it sends the technical details of the failure, the app version, and the device model and operating-system version under a random per-install id. A report contains no record contents, names, email addresses, workspace ids, request bodies or URL query strings, and IP addresses are not stored.

Then: they age out automatically at the processor (Sentry). Because a report is not tied to a person or a Customer, there is nothing to look up or delete for an individual. They are never used for advertising or profiling. The app also keeps one bounded crash log on the device, shown on its More screen, which leaves the device only if the User chooses to send a screenshot of it.

Push notification device tokens

Kept for: until the User turns notifications off or signs out, or until the push service reports the token as no longer valid. The mobile field app registers a token, tied to the User’s login, when the User turns notifications on.

Then: the token is deleted on sign-out or opt-out (retried at the next launch if the device was offline). A token the push service reports as no longer registered is deleted by the delivery process, and every token is purged with the workspace.

Marketing-site analytics

Kept for: the default retention period of Google Analytics 4, in aggregate.

Then: this applies to sitewideops.com only. The production Service, web and mobile, sends nothing to any analytics or advertising service. The mobile app’s crash reports are diagnostics, not usage analytics, and carry no record of what a User did.

How data is deleted

Every commitment above is backed by a mechanism that exists in the product today.

• Self-serve export. A workspace administrator can export a complete backup of every record in the workspace at any time from Settings → Backup & Import Tools. This is how the export window above is met without any action from SitewideOps.
• Workspace purge. Retiring a workspace is a deliberate two-stage procedure. First the workspace is closed: access ends and a full backup snapshot is taken. Then it is purged: every row the workspace owns is deleted, irreversibly. The two stages prevent accidental destruction while making complete deletion provable.
• In-product deletion. Removing a record day to day archives it rather than erasing it, so the Customer’s own audit trail stays intact. The audit trail is part of Customer Data and belongs to the Customer. Permanent deletion happens for the whole workspace through the purge above.
• Integration disconnect. Disconnecting an accounting or bank connection in Settings → Integrations stops the sync and discards the stored tokens for that connection. For a bank connection the token is revoked at the provider first, as described above. Unmapping a bank account from a company card stops new transactions for that account but keeps the connection and its token until the connection itself is disconnected.
• Communication opt-outs. SMS recipients can stop all messages by replying STOP, which is honored automatically at the delivery layer. Email recipients can unsubscribe from non-essential mail with the link in the message.

De-identification, where it is used in place of deletion, means removing or irreversibly transforming every field that identifies a person or the Customer, so that what remains cannot reasonably be linked back to either.

Deletion and access requests

Send requests to contact@sitewideops.com. We acknowledge and act on them within 30 days. Requests from individuals are forwarded to the controlling Customer where appropriate.

When a Customer’s employee, customer or contact asks about records that Customer keeps in SitewideOps, the Customer controls those records, and we help the Customer respond.

Exceptions

Data otherwise due for deletion may be kept longer only when:

• it is required by law, regulation or a valid legal process;
• it is reasonably necessary for an active dispute, a security investigation or fraud prevention; or
• it exists in rolling backups that have not yet expired, in which case it is not restored except for disaster recovery.

When an exception applies, the data is kept only as long as the exception requires and is then deleted under the normal schedule.

Review

We review this policy at least once a year, and whenever a change to the product or its infrastructure adds a new kind of data or a new service provider (for example, a new integration). Each review updates the effective date. If a retention period changes, the Privacy Policy is updated and Customers are notified as its “Changes” section describes.

Questions about this policy can go to contact@sitewideops.com.