Security

• Separation between companies. Every company’s data is isolated, and that isolation is enforced by the system rather than by convention, so one customer’s workspace is never reachable from another’s.
• Least privilege inside a company. Access follows roles, and a denial always beats a grant. A role that should not see financials never sees financials.
• Encryption. Data is encrypted in transit and at rest, including backups.
• Authentication. Unique credentials per person, multi-factor authentication support, and session management and revocation.
• Separated environments. Production is separate from testing, and production data is not used to build or test.
• Monitoring and audit. Security-relevant activity is logged and retained, and anomalies raise alerts.
• Controlled change. Changes are reviewed and tested before release, dependencies are scanned, and issues are remediated on a severity-based schedule.
• People. Background screening where lawful, confidentiality agreements, security training, and same-day access revocation when someone leaves.
• Vendors. Every vendor that touches customer data is reviewed and bound in writing to obligations at least as strict as our own, and we stay responsible for them.

We describe our safeguards at this level deliberately. Publishing the internal detail of how a system is defended is useful mainly to the people trying to get past it. Customers and prospects running a security review can request specifics under confidentiality through the contact page, and we complete security questionnaires as part of that.

If we confirm a security incident affecting a customer’s personal information, we notify that customer without undue delay and within 72 hours. The notice covers what happened, what was affected, what it likely means, what we are doing about it, and who to talk to, and we keep updating it as the investigation develops. We support customers in meeting their own notification obligations, and we do not treat a notification as an admission of fault while facts are still being established.

Customers have an obligation in the other direction: tell us within 24 hours if credentials are compromised or someone reaches a workspace who should not have.

If you have found a security issue in ContractorX, we want to hear about it before anyone else does. Send it through the contact page with “Security” in the subject, and include enough detail to reproduce it: the affected URL or feature, the steps, and what you were able to access or do.

Our commitment to you. We will acknowledge your report, investigate it, keep you updated on what we find, and tell you when it is fixed. If you follow the rules below, we will not pursue or support legal action against you for your research, and we are glad to credit you publicly once the issue is resolved, if you want that.

The rules. Test only against your own account and data. Do not access, modify, or retain anyone else’s data, and stop as soon as you have established that a vulnerability exists. Do not run denial-of-service testing, spam, social engineering, or physical attacks. Do not use automated scanners that degrade the service for other customers. Give us a reasonable opportunity to fix the issue before disclosing it publicly.

We do not currently run a paid bug bounty. That is a budget decision, not an indication of how seriously we take reports.

Availability commitments, support response targets, backup and recovery practice, and the credits that apply when we miss are in the Service Commitment. How we handle data as a processor for our customers, including subprocessors and audits, is in the Data Processing Addendum. This page is current as of August 20, 2026.