Version 1.0 · September 3, 2026
This document describes the security measures Job-Dox, LLC maintains for the Cortex platform. It is provided to subscribers on request under Section 9 of our Data Processing Addendum and is not a contract document. Job-Dox may revise it as its practices evolve; the binding commitment is the outcome-level obligation in Section 5 of the Addendum.
| Item | Detail |
|---|---|
| Hosting model | Cloud-hosted. The application and its serverless functions run on Netlify; data and files are stored in Google Cloud. |
| Infrastructure providers | Netlify, Inc. and Google LLC, with Amazon Web Services for email delivery, DNS, and application infrastructure. |
| Regions | United States. Primary processing in us-west-2, with us-east-1 used for DNS management. |
| Physical security | Production infrastructure resides in facilities operated by our infrastructure providers, which maintain physical access controls, environmental safeguards, and continuous monitoring. Job-Dox personnel have no physical access to production hardware. |
| Environment separation | Production and non-production environments are separate infrastructure projects. Production data is not used in development or staging; sample data is synthesised. |
| Tenancy model | Multi-tenant with logical isolation. Every subscriber’s data is scoped beneath a per-company path, and database security rules scope every read and write to the requesting user’s own company. |
| Item | Detail |
|---|---|
| Encryption in transit | All traffic between subscriber devices and the platform is encrypted using TLS, terminated at our provider’s edge. We do not currently enforce a minimum TLS version above our provider’s default, and HTTP Strict Transport Security is not currently configured. |
| Encryption at rest | Subscriber data, including photographs and documents, is encrypted at rest by our infrastructure providers for both database and object storage. This is provider-managed encryption; we do not configure or manage encryption keys. |
| Key management | Provider-managed. We do not use customer-managed encryption keys. One exception: stored payment field data is encrypted at the application layer using a key held outside the database, so a database export alone does not expose it. |
| Data location | All subscriber data on Job-Dox-controlled infrastructure is stored within the United States. Certain sub-processors are incorporated outside the United States; see our Sub-processors page. |
| Backups | Backup and point-in-time recovery are provider-default. We do not currently operate a configured backup schedule, a documented restoration procedure, or scheduled restoration testing. |
| Data deletion | On cancellation, data is retained 60 days and then permanently deleted from production systems. Where an account is terminated for cause, the period is 30 days. See our Terms of Service. |
| Item | Detail |
|---|---|
| Subscriber access | Role-based access control within the platform, on a numeric permission scale. Each authorized user requires unique credentials. Credential sharing is prohibited under our Terms of Service. |
| Tenant isolation | Enforced at the database layer rather than in application code. Security rules verify that the requesting user’s company matches the data being accessed, and separately that the user’s permission level meets the threshold for the operation. |
| Authentication | Email and password. Our signup form requires a minimum of eight characters; our identity provider enforces a six-character minimum. We do not currently enforce additional password complexity rules. Multi-factor authentication is not currently offered to subscribers. On our native mobile applications, biometric unlock is available as a device-level convenience; it is not a second authentication factor. |
| Administrative access | Job-Dox personnel access to production data is limited by role and business need and granted on the principle of least privilege, controlled by a support privilege on the personnel account. Administrative actions taken through our server-side functions — including data export, account provisioning, and staff changes — are recorded in the audit log described in Section 4. Support access to subscriber records through the application interface is authorised by the support privilege but is not individually logged. |
| Access review | We do not currently operate a scheduled access review cycle. Access is revoked on separation or role change. |
| Session management | Sessions persist until the user signs out. We do not currently enforce an idle session timeout or a concurrent session limit. |
| Item | Detail |
|---|---|
| Application logging | Access to and activity within the platform is logged. Each entry records the acting user’s identity, email, and permission level, whether the action was taken under support privilege, the action itself, its target, the subscriber company, the outcome, the source IP address, the browser user agent, and a timestamp. |
| Log retention | 400 days, enforced by an automatic expiry on each record. |
| Subscriber visibility | Audit logs are internal. Subscribers cannot currently view their own activity log within the platform. |
| Anomaly detection | We operate application error monitoring, which alerts on new and spiking client-side exceptions. We do not currently operate security-specific anomaly detection: there is no failed-authentication threshold alerting, brute-force detection, or anomalous-access alerting. |
| Item | Detail |
|---|---|
| Patching | Infrastructure patching is handled by our providers. Application dependency updates are applied manually as part of ordinary development. |
| Dependency scanning | Not currently performed. We do not operate automated scanning of third-party libraries. |
| Penetration testing | Not currently performed. |
| Change control | Changes are deployed from version control. Non-production branches build to isolated preview deployments, allowing changes to be reviewed in a running environment before merge. An automated test suite exists but is not currently executed as a deployment gate, and merges are not currently subject to a required-review policy. |
| Item | Detail |
|---|---|
| Confidentiality | All personnel with access to subscriber data are bound by written confidentiality obligations. |
| Access limitation | Access to production subscriber data is limited to personnel who require it, and every such access is logged. |
| Background checks | Not currently performed. |
| Security training | We do not currently operate a formal security awareness training programme. |
| Offboarding | Access is revoked promptly upon separation or role change. |
Where a security incident affects subscriber personal data, Job-Dox notifies the affected subscriber without undue delay and within seventy-two (72) hours of confirming the incident, in accordance with Section 8 of our Data Processing Addendum. Notification includes the nature and timing of the incident, the categories and volume of data affected, likely consequences, and remediation steps.
We do not currently maintain a formally documented incident response runbook. The notification commitment above stands regardless.
As controller of the data it submits, the subscriber is responsible for determining whether onward notification to individuals or regulators is required.
| Item | Detail |
|---|---|
| Uptime commitment | 99% monthly availability, excluding scheduled maintenance. See Section 11.2 of our Terms of Service. |
| Recovery objectives | Formal recovery time and recovery point objectives are not currently defined. |
| Maintenance windows | We do not currently operate a fixed maintenance window. Deployments are continuous and are generally transparent to users. |
| Continuity testing | Not currently performed. |
A current list of third parties that process subscriber data on our behalf is published on our Sub-processors page. Each is bound by written data protection obligations no less protective than those in our Data Processing Addendum.
Automated analysis using artificial intelligence is an integral part of the platform, and relevant data is transmitted to a model provider for processing. Model providers appear on our Sub-processors page, and the commercial terms governing retention of submitted data and its use for model training are described there.
| Item | Detail |
|---|---|
| SOC 2 Type II | Not currently held. |
| ISO 27001 | Not currently held. |
| HIPAA | Cortex is not offered as a HIPAA-compliant environment. See Section 4.2 of our Data Processing Addendum. |
| PCI DSS | Cardholder data is not stored in Cortex. Subscription billing is handled by a PCI-compliant payment processor. |
| State privacy laws | Job-Dox acts as a processor under the Texas Data Privacy and Security Act and comparable state statutes. See our Data Processing Addendum. |
Security questions, questionnaire requests, and vulnerability reports: info@job-dox.com
Under Section 9 of our Data Processing Addendum, subscribers may request compliance documentation once per twelve-month period.