Security policy

Last updated: 25 August 2026

This policy describes the technical and organizational measures Crosstown Tech uses to protect customer data in QuickBooks Timesheet Sync for Jira & Tempo ("the app") and in the systems that support it. It is the vendor security policy for this app; Privacy covers what data the app reads, writes and stores.

1. Architecture and hosting

• The user interface is an Atlassian Forge Custom UI app. It runs inside your Jira site, on Atlassian's infrastructure, under Forge's runtime isolation.
• The backend runs on Convex Cloud in the United States. It holds all QuickBooks credentials and makes every QuickBooks API call. No QuickBooks token ever reaches the browser.
• There are no self-managed servers, virtual machines or containers, and no administrator-accessible operating system. Patching, network controls and physical security are the responsibility of Atlassian and Convex, whose platforms carry their own certifications.
• Only two endpoints accept unauthenticated requests: the Intuit OAuth callback and the QuickBooks webhook. Both are cryptographically verified before anything is processed — see section 3.

2. Encryption

• In transit: all traffic uses HTTPS with TLS 1.2 or higher — between the Jira user interface and the backend, and between the backend and Intuit, Atlassian and Tempo. No unencrypted protocol is used anywhere.
• At rest: the QuickBooks refresh token and the optional Tempo API token are encrypted with AES-256-GCM under a key held in a deployment environment variable, never in source control. Neither value is ever returned to the browser — they can only be replaced or removed. QuickBooks access tokens are short-lived and held only as a server-side cache.
• The underlying database is encrypted at rest by the platform.

3. Authentication and authorization

• No passwords. The app issues, stores and verifies no passwords of its own. Access to QuickBooks uses Intuit OAuth 2.0; access to Jira uses short-lived tokens issued by Atlassian Forge.
• Every application request is authenticated with an Atlassian-signed Forge invocation token, verified server-side on every call. A request without a valid token is rejected.
• Privileged actions require a live permission check. Connecting or disconnecting QuickBooks, reading master data and changing configuration require the caller to hold the Jira ADMINISTER permission, checked against Jira at call time rather than trusted from the client.
• OAuth CSRF protection: the authorization flow carries a signed state parameter (HMAC), verified on callback. A callback with a missing, altered or replayed state is discarded.
• Webhooks are signature-verified: incoming QuickBooks webhooks are checked against Intuit's HMAC signature over the raw request body before the payload is parsed.
• Least-privilege scopes: the app requests one QuickBooks scope, com.intuit.quickbooks.accounting — no payments, payroll or banking — and only the Jira scopes declared in its Forge manifest. Jira access is read-only.

4. Tenant isolation

Every stored record is keyed to the Jira installation that created it, and no query crosses that boundary. One customer cannot reach another customer's data through the application. Jira reads run as the identity of the person who connected QuickBooks, so the app never sees issues that person cannot see, and the per-issue panel returns nothing without a user token.

5. Data minimization

The app stores no personal data: people are recorded only by their Atlassian account id, and no name or email address is written down — not for your Jira users, and not for your QuickBooks employees. Names are fetched live when a screen is drawn and then discarded. The app stores no QuickBooks financial records, invoices, bank or payroll data. What is stored, and for how long, is listed in full on the privacy page.

6. Internal access control

• Crosstown Tech is a small studio; access to production systems is limited to the owner.
• Administrative accounts for the platforms we use (Atlassian, Convex, Intuit, the DNS and hosting providers) are protected with multi-factor authentication. No shared logins are used.
• Production secrets live only in the backend's environment variables. They are not stored in source control, in the front end, or on developer machines.
• Customer data is not copied to laptops, spreadsheets or analytics tools, and is not used for development or testing. Development runs against a separate deployment and an Intuit sandbox company.

7. Secure development

• All code is kept in version control with a reviewed change history; production deploys are made from that source, never edited in place.
• Third-party dependencies are installed from npm, kept current, and checked against published security advisories; vulnerable packages are updated promptly.
• Input from the client is validated server-side. The backend is written in TypeScript against a typed schema, and database access goes through that schema rather than string-built queries.
• Automated tests cover the QuickBooks error and authentication paths, including expired and revoked credentials.
• We follow Atlassian's App Security Requirements and Intuit's security guidance for published apps.

8. Credential lifecycle

• The QuickBooks refresh token is replaced on every refresh, following Intuit's rotation, so a superseded value is never retained.
• Connections that have been idle are treated as expiring: the app warns the administrator from day 80 and stops using the credential at day 100 rather than waiting for a rejection.
• If Intuit rejects a stored token (invalid_grant), the connection is marked as needing re-authorization within one five-minute cycle and the administrator is told what to do. This is also what covers a disconnect performed on the QuickBooks side.
• Disconnecting QuickBooks in the app revokes the token with Intuit and deletes the stored credential immediately.

9. Logging and monitoring

• The app keeps a per-installation run history — sync counts, timings, errors and the Intuit transaction id for failed calls — surfaced in the app's own dashboard so administrators can see and report problems themselves.
• Platform logs are retained for a short window for debugging and are accessible only to the owner through an MFA-protected account. They are not shared with third parties and are not used for any purpose other than operating the app.
• Credentials and tokens are never written to logs.

10. Vulnerability management

• Dependency advisories are monitored and applied on an ongoing basis; security fixes take priority over feature work.
• The app's attack surface is deliberately small: two unauthenticated endpoints, both signature-verified, and no public database, admin console or file upload path.
• Findings — whether from advisories, our own review, or a report from outside — are triaged on receipt, fixed, and deployed as soon as a fix is validated. Forge and Convex both deploy in minutes, so there is no maintenance window to wait for.

11. Reporting a vulnerability

We welcome reports from customers and security researchers. Email security@crosstowntech.com (or support@crosstowntech.com) with enough detail to reproduce the issue. We will acknowledge within 2 business days and keep you updated until it is resolved. Please do not publicly disclose an unpatched issue, and please do not test against another customer's data — we will not pursue action against researchers who follow this.

12. Incident response

If we become aware of a security incident affecting customer data:

• We investigate and assess scope within 24 hours of discovery, and take immediate steps to contain it — including revoking credentials and suspending syncing for affected installations.
• Affected customers are notified within 72 hours, in line with GDPR Article 33, with what happened, what data was involved, and what we have done about it.
• Where the Atlassian Marketplace is involved, we follow Atlassian's App Security Incident Management Guidelines, and we notify Intuit where QuickBooks data is affected.
• We complete a post-incident review and publish or share the remediation with affected customers.

To date, Crosstown Tech has had no known security breach affecting customer data.

13. Availability and continuity

Availability, redundancy and backups are provided by the underlying platforms — Atlassian Forge for the user interface and Convex Cloud for the backend and database. The app is not on the critical path for either Jira or QuickBooks: if syncing is interrupted, worklogs stay in Jira and time activities already written stay in QuickBooks, and the app reconciles when it resumes. Nothing is lost by an outage.

14. Sub-processors

• Convex — application backend, database and scheduled jobs (United States).
• Atlassian — hosts the app's user interface inside your Jira site.
• Intuit — the QuickBooks Online API the app writes to.
• Vercel — hosts this marketing site only; no customer data.

No data is sold, shared with advertisers, or used to train models.

15. Compliance

• We process data in accordance with the GDPR. A Data Processing Agreement is available to customers on request.
• Crosstown Tech is based in Canada; Canada holds an EU adequacy decision. Transfers to the United States are governed by Standard Contractual Clauses through our sub-processors' data protection addendums.
• We hold no certification of our own and do not claim one. Infrastructure security rests on our providers' certifications — Atlassian and Convex publish their own SOC 2 and related reports.

16. Changes to this policy

We update this policy as the app changes. Material changes are reflected here with a new "last updated" date.

17. Contact

Security reports: security@crosstowntech.com. General support: support@crosstowntech.com or the support portal. Please include your Jira site URL.