Security
It's the foundation everything else is built on. pace● handles sensitive candidate data and high-stakes hiring decisions — our security practices reflect that responsibility.
Encryption
All data transmitted between clients and our servers is encrypted using TLS, managed and enforced by our hosting platform (Replit). We rely on the platform's certificate management and TLS termination rather than managing our own certificate infrastructure.
Sensitive fields — such as TOTP secrets and two-factor authentication tokens — are encrypted using AES-256-GCM with authenticated encryption. Passwords are hashed using bcrypt. We do not currently operate a dedicated key management service (KMS) or automated key rotation — encryption keys are managed via environment variables.
Infrastructure
pace● is hosted on Replit, a managed cloud platform. Infrastructure provisioning, OS-level security patches, and networking are handled by the platform. We do not self-manage servers, VPCs, or availability zones.
Network-level protections such as DDoS mitigation and traffic management are provided by the hosting platform. We do not currently configure our own WAF, network segmentation, or firewall rules at the application level.
We have not yet conducted formal third-party penetration testing. This is on our roadmap as we mature our security programme and scale enterprise operations.
We monitor software dependencies for known vulnerabilities using standard tooling. We do not currently have automated CI/CD security gates that block deployments — this is an area we plan to strengthen.
Access Controls
Access is controlled through role-based permissions (manager and interviewer roles). Multi-factor authentication (TOTP) is available for all users. Sessions use httpOnly, secure cookies with cryptographically random session identifiers. We do not currently have automated access reviews or short-lived credential systems.
Each organisation's data is isolated through application-level middleware that enforces company context on every request. This is middleware-enforced isolation, not architectural separation — all tenants share the same database with scoped queries. Cross-tenant access is prevented by the middleware layer.
We have not yet begun a formal SOC 2 audit. As we grow and serve enterprise customers, achieving SOC 2 Type II certification is on our roadmap. We are building foundational controls now — access management, session handling, and audit logging — that will support a future engagement.
Incident Response
We do not currently have automated monitoring, SIEM, or real-time alerting systems in place. Anomaly detection is manual. Building automated monitoring is on our roadmap.
We are developing documented incident response procedures. We do not currently have a formal on-call rotation or 24/7 coverage. Response is handled by the engineering team during business hours.
In the event of a confirmed data breach, we are committed to notifying affected customers within 72 hours in line with GDPR Article 33 requirements. Notification templates and processes are being formalised.
We conduct post-incident reviews to identify root causes and improve processes. As we mature, we plan to formalise blameless post-mortem practices and systematic control improvements.
Frequently Asked
Production access is limited to a small number of engineers on a least-privilege basis. Within the application, access is constrained by role-based permissions (manager and interviewer roles) and tenant-isolation middleware that scopes every query to the customer's organisation. Files in object storage record their owning company at upload time, and every download request re-checks that the requester belongs to that company before the object is served — so a leaked or guessed link cannot be opened by anyone outside the owning organisation. Sensitive workspace actions write to an internal audit log so we can reconstruct who did what and when.
If a sub-processor (Anthropic, Resend, Google Cloud Storage, or Replit) notifies us of a security incident affecting your data, we treat it as our own incident: we assess the blast radius against our processing records, contain any onward exposure, and notify affected customers. For confirmed personal-data breaches we commit to GDPR Article 33 timing — notification within 72 hours of becoming aware. We will share what we know, what we don't yet know, and what we are doing about it, rather than waiting for a polished narrative.
Honestly: not yet. Sign-in today is via email and password (with TOTP-based two-factor available) and OAuth through Google or LinkedIn. SAML 2.0 SSO and SCIM provisioning are on the roadmap for enterprise tiers but are not shipped. If SAML or SCIM is a hard procurement requirement for you, tell us — it helps us prioritise, and we will be straight with you about timing rather than overpromise.
The audit log captures workspace actions that change the state of hiring data or who can see it: candidate lifecycle events (creation, stage changes, decisions, archival, deletion, anonymisation), score submissions and edits, interview lifecycle (creation, completion, archival, deletion, retry of analysis), job and role changes, competency edits (including AI-generated vs user-edited), team-membership changes (invitations, role changes, removals), transcript views, committee report exports, billing-state changes (subscription, refunds, disputes), and screening question updates. Each entry records the actor, the affected resource, the action, and a timestamp. Authentication events (login, password reset, two-factor enrolment) are not yet in the audit log — that gap is on our roadmap. We use the log for our own incident response today and plan to expose a customer-facing view of admin actions to managers in a future release.
Get Started
Try pace● free and see our security practices firsthand. Questions? Our team is ready to walk through our architecture with you.