Security & Trust
Clear controls.Careful data handling.
A plain-language overview of how Ovii protects accounts, hiring workflows, and customer data, plus the control areas we map across privacy and assurance frameworks.
Identity & Access
Controls that govern authentication, authorization, access boundaries, and identity lifecycle management.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| User authentication | Implemented | How ATS users prove identity before accessing protected product workflows. | SOC 2, ISO/IEC 27001 |
| Password hashing | Implemented | How user passwords are stored using one-way cryptographic protection rather than plain text. | SOC 2, ISO/IEC 27001 |
| Password reset security | Implemented | How account recovery and reset flows avoid unauthorized account takeover. | SOC 2, ISO/IEC 27001 |
| Single sign-on | Implemented* | Whether enterprise identity providers can be used to centralize user access management. | SOC 2, ISO/IEC 27001 |
| Session management | Implemented | How authenticated sessions are created, validated, renewed, and ended. | SOC 2, ISO/IEC 27001 |
| Session timeout | Implemented | Whether inactive or aged sessions expire according to defined security rules. | SOC 2, ISO/IEC 27001 |
| Refresh token rotation | Implemented | How long-lived session renewal tokens are rotated or invalidated to reduce replay risk. | SOC 2, ISO/IEC 27001 |
| Account lockout / brute-force protection | Implemented | Controls that slow or block repeated failed sign-in attempts. | SOC 2, ISO/IEC 27001 |
| Failed-login monitoring | Implemented | Visibility into failed authentication attempts and possible abuse patterns. | SOC 2, ISO/IEC 27001 |
| Role-based access control | Implemented | How access to routes, actions, and data is segmented by user role. | SOC 2, ISO/IEC 27001, GDPR |
| Least-privilege permissions | Partial | Whether users and admins receive only the access needed for their responsibilities. | SOC 2, ISO/IEC 27001 |
Application Security
Controls focused on secure request handling, browser protections, route exposure, and common web application risks.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Protected API authentication | Implemented | How protected endpoints require a valid identity context before processing requests. | SOC 2, ISO/IEC 27001 |
| Public route allowlist review | Implemented | How publicly accessible endpoints are intentionally identified and reviewed rather than exposed by accident. | SOC 2, ISO/IEC 27001 |
| Output encoding / XSS protection | Implemented | How the product avoids returning untrusted content in unsafe ways that could execute in the browser. | SOC 2, ISO/IEC 27001 |
| CSRF protection | Implemented | Whether browser-based state-changing requests are protected from cross-site request forgery where relevant. | SOC 2, ISO/IEC 27001 |
| CORS restrictions | Implemented | How browser origins are restricted for API access and callback handling. | SOC 2, ISO/IEC 27001 |
| Safe error handling | Partial | How the application returns useful errors without leaking internal details or sensitive information. | SOC 2, ISO/IEC 27001 |
| File upload validation | Implemented | How uploaded content is checked before it becomes part of product workflows or storage. | SOC 2, ISO/IEC 27001 |
| File type restrictions | Implemented | How allowed formats are limited for uploads, media handling, and processing pipelines. | SOC 2, ISO/IEC 27001 |
| Rate limiting | Partial | Whether high-risk endpoints are restricted to reduce abuse, scraping, or denial-of-service patterns. | SOC 2, ISO/IEC 27001 |
| CAPTCHA / bot protection | Not implemented | Whether public-facing flows use controls to reduce automated abuse. | SOC 2, ISO/IEC 27001 |
| Security regression tests | Partial | Whether key security behaviors are covered by repeatable automated tests. | SOC 2, ISO/IEC 27001 |
| Route-level security testing | Not implemented | Whether the highest-risk endpoints are explicitly tested for authorization and isolation failures. | SOC 2, ISO/IEC 27001 |
Data Protection
Controls that focus on storage, transfer, deletion, recovery, and scoped handling of customer and user data.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Encryption in transit | Implemented | How traffic is protected while moving between users, services, and external providers. | SOC 2, ISO/IEC 27001, GDPR |
| Sensitive data minimization | Implemented | Whether the platform limits the collection and retention of data that is not needed. | GDPR, ISO/IEC 27001 |
| Resume and generated document handling | Implemented | How ATS resume data and generated resume documents are stored, processed, and delivered through authenticated product workflows. | SOC 2, ISO/IEC 27001, GDPR |
| Secure data export | Partial | How exports are restricted, logged, and delivered securely when user data leaves the platform. | SOC 2, ISO/IEC 27001, GDPR |
| Audit trail for sensitive data access | Implemented | Whether access to important records can be traced after the fact for review or investigation. | SOC 2, ISO/IEC 27001, GDPR |
| Data retention rules | Implemented | Whether OVII publicly documents retention and deletion expectations for key ATS data categories. | GDPR, ISO/IEC 27001 |
| Account deletion workflows | Implemented | How authenticated account deletion deactivates the account, removes access, invalidates active sessions, blocks future logins, and retains related records where legal or operational requirements apply. | GDPR, SOC 2, ISO/IEC 27001 |
Privacy & GDPR
Controls and operational processes tied to personal data handling, user rights, and privacy governance.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Privacy notice | Implemented | Whether OVII clearly explains data collection, use, sharing, and retention in public documentation. | GDPR |
| Terms and recording consent gates | Implemented | How OVII stores account terms acceptance and uses explicit pre-start gates before candidate assessment monitoring or video recording begins. | GDPR |
| Privacy rights request path | Implemented | How users request access to personal data through account tools or OVII contact channels, with privacy-related inquiries targeted for response within 30 days. | GDPR |
| Data correction process | Implemented | How candidates can correct inaccurate or outdated personal data, including communication details, in their profile and resume. | GDPR |
| Data deletion / erasure process | Implemented | How authenticated users can request account deletion, with access removed, active sessions invalidated, future logins blocked, and records retained where legal or operational requirements still apply. | GDPR |
| Data portability process | Implemented | How candidates can export ATS profile and resume data in user-consumable formats, including downloadable PDF and editable Word resume exports. | GDPR |
| DPA process | Implemented | Whether ATS customer data processing terms are incorporated into OVII’s recruiter terms when OVII processes candidate data on the customer’s behalf. | GDPR |
| Subprocessor disclosure | Implemented | Whether customers can review the named third parties involved in relevant ATS customer-data processing. | GDPR, SOC 2, ISO/IEC 27001 |
Logging, Monitoring & Audit
Controls that support traceability, anomaly detection, service visibility, and audit readiness.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Security event logging | Implemented | Whether security-relevant events are captured for review and investigation. | SOC 2, ISO/IEC 27001 |
| Business action audit logging | Implemented | Whether sensitive tenant-facing ATS business operations create a traceable audit record. | SOC 2, ISO/IEC 27001, GDPR |
| ATS admin action logging | Implemented | Whether privileged tenant-admin ATS actions are recorded in a reviewable way. | SOC 2, ISO/IEC 27001 |
| Authentication event logging | Partial# | Whether sign-in, sign-out, refresh, and lockout events are visible for audit and abuse detection. | SOC 2, ISO/IEC 27001 |
| Failed-login logging | Implemented | Whether repeated authentication failures can be identified and reviewed. | SOC 2, ISO/IEC 27001 |
| Durable audit persistence | Implemented | Whether audit events that reach OVII's audit pipeline are durably persisted with retry and dead-letter handling and remain available for later review. | SOC 2, ISO/IEC 27001 |
| Centralized audit log review | Implemented | How ATS audit logs are centrally collected, retained, filtered, and exported for review outside of individual request execution. | SOC 2, ISO/IEC 27001 |
| Queue retry and failure visibility | Implemented | Whether internal teams can see retry attempts, failure reasons, and dead-lettered background jobs through operational dashboards. | SOC 2, ISO/IEC 27001 |
| DLQ monitoring | Implemented | Whether internal teams monitor dead-letter queues and review messages that have exhausted retry handling and require manual follow-up. | SOC 2, ISO/IEC 27001 |
| Audit evidence availability | Implemented | Whether business audit logs are durably stored and can be queried or exported for later review. | SOC 2, ISO/IEC 27001 |
Infrastructure & Platform Security
Controls that apply to environments, runtime infrastructure, storage systems, and operational hosting posture.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Environment separation | Implemented | How development and production environments use separate configuration profiles, API endpoints, and queue namespaces. | SOC 2, ISO/IEC 27001 |
| Production network access boundaries | Implemented | Whether production database and internal application surfaces are restricted through private-network design and host-specific access rules. | SOC 2, ISO/IEC 27001 |
| Firewall / edge protection | Implemented | How Azure NSG rules and Nginx HTTPS reverse-proxy controls restrict public ingress to OVII internet-facing systems, with Nginx and system logs available for review. | SOC 2, ISO/IEC 27001 |
| Edge request throttling | Implemented | How Nginx applies edge request throttling to reduce common web abuse against OVII internet-facing endpoints. | SOC 2, ISO/IEC 27001 |
| Secure server configuration | Implemented | How OVII production servers use documented HTTPS, private-database access, managed service runtime, and environment-based secret configuration baselines. | SOC 2, ISO/IEC 27001 |
| Private database access controls | Implemented | How OVII production databases use private-network access, restricted host-based application credentials, and validated schema configuration. | SOC 2, ISO/IEC 27001 |
| File upload validation controls | Implemented | How OVII validates file types, sizes, and upload constraints for profile images and async-media uploads. | SOC 2, ISO/IEC 27001, GDPR |
| Runtime version baselines | Implemented | How OVII documents and pins production runtime and dependency baselines across Java, Spring Boot, MySQL, Nginx, and frontend/backend packages. | SOC 2, ISO/IEC 27001 |
| Dependency version tracking | Implemented | How OVII tracks third-party software through backend and frontend dependency manifests, lockfiles, and version-pinned package configuration. | SOC 2, ISO/IEC 27001 |
Secure SDLC & Change Management
Controls that govern how product changes are designed, reviewed, tested, and released.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| AI-assisted pre-merge review | Implemented | How OVII uses LLM-assisted review of code changes before merge to catch issues before they become part of the product. | Customer diligence |
| CI checks | Not implemented | Whether builds, tests, and other automated checks run before release. | SOC 2, ISO/IEC 27001 |
| Frontend static linting | Implemented | How OVII maintains an ESLint configuration and npm lint command to check frontend JavaScript, React Hooks, React Refresh, unused variables, and console usage during development. | SOC 2, ISO/IEC 27001 |
| Manual production-change validation | Implemented | How OVII uses founder-operated release steps, health checks, Nginx validation, public endpoint checks, and rollback instructions when production code or edge configuration changes. | SOC 2, ISO/IEC 27001 |
| Deployment traceability | Pending review | Whether changes can be traced from code to release history and production state. | SOC 2, ISO/IEC 27001 |
| Versioned database migrations | Implemented | How OVII keeps database schema changes in versioned Flyway migration files and configures production startup to validate and apply migrations from the tracked migration path. | SOC 2, ISO/IEC 27001 |
Incident Response & Recovery
Controls that define how OVII prepares for, responds to, communicates about, and learns from incidents.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Incident response plan | Implemented | How OVII uses a documented founder-operated runbook for security, privacy, availability, data integrity, account-access, infrastructure, and provider-related incidents. | SOC 2, ISO/IEC 27001 |
| Severity classification | Implemented | How OVII classifies incidents into critical, high, and standard severity levels based on suspected data, account, tenant-isolation, availability, infrastructure, provider, and control impact. | SOC 2, ISO/IEC 27001 |
| Founder incident ownership | Implemented | How OVII assigns current-stage incident lead, engineering lead, customer communications, privacy assessment, and provider-liaison responsibilities to the founder / operator. | SOC 2, ISO/IEC 27001 |
| Incident evidence preservation | Implemented | How OVII identifies incident evidence to preserve, including audit records, auth events, account/user/company IDs, service logs, edge logs, queue state, provider event IDs, deployment context, screenshots, reports, and response actions. | SOC 2, ISO/IEC 27001 |
| Customer communication workflow | Implemented | How OVII prepares direct customer email or status-page updates for meaningful customer-facing impact, including known impact, current status, workaround guidance, OVII actions, and follow-up timing. | SOC 2, ISO/IEC 27001, GDPR |
| Privacy notification assessment | Implemented | How OVII assesses whether personal data or ATS customer data may be affected, documents data categories and impact, considers customer/controller responsibilities, and evaluates whether external privacy/legal guidance or notification is required. | GDPR, ISO/IEC 27001 |
| Post-incident review | Implemented | How Sev 1 / Sev 2 incidents, and Sev 3 incidents that reveal recurring control gaps, are closed with a documented review template, timeline, evidence summary, notification assessment, lessons learned, owners, due dates, and validation evidence. | SOC 2, ISO/IEC 27001 |
Vendor & Third-Party Risk
Controls for vendors, subprocessors, service providers, and externally integrated platforms.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Vendor inventory | Pending review | Whether OVII maintains a list of relevant vendors and service providers. | SOC 2, ISO/IEC 27001, GDPR |
| Vendor risk review | Pending review | How vendors are assessed before they are used in production or with customer data. | SOC 2, ISO/IEC 27001, GDPR |
| Subprocessor approval process | Pending review | Whether vendors handling customer data are reviewed through a defined process. | SOC 2, ISO/IEC 27001, GDPR |
| Vendor access restrictions | Pending review | How vendor access to systems and data is limited and controlled. | SOC 2, ISO/IEC 27001 |
| Vendor offboarding | Pending review | How access and operational dependency are removed when vendor relationships end. | SOC 2, ISO/IEC 27001 |
| Contractual security clauses | Pending review | Whether relevant contracts include security, confidentiality, and incident expectations. | SOC 2, ISO/IEC 27001, GDPR |
| Privacy review for vendors | Pending review | Whether privacy implications are assessed before third parties process personal data. | GDPR, ISO/IEC 27001 |
| AI provider data handling review | Pending review | How AI model providers and data processors are evaluated for customer-data use. | SOC 2, ISO/IEC 27001, GDPR |
| Payment processor segregation | Pending review | How payment handling is separated from broader product processing wherever possible. | SOC 2, ISO/IEC 27001 |
Documents & Assurance
Public documents and customer-facing assurance materials that typically support diligence requests.
| Control | Status | What this covers | Frameworks |
|---|---|---|---|
| Privacy policy | Implemented | Public document describing how OVII handles personal information. | GDPR, Customer diligence |
| Terms of service | Implemented | Public contract terms describing platform usage expectations and boundaries. | Customer diligence |
| Acceptable use policy | Implemented | Public rules for proper platform use and prohibited behavior. | Customer diligence |
| Refund / billing policy | Implemented | Public billing and refund expectations for applicable product surfaces. | Customer diligence |
| Subprocessor list | Implemented | Whether OVII publishes or can share the named vendors involved in relevant ATS customer-data processing. | GDPR, Customer diligence |
| Security questionnaire request path | Implemented | Whether customers have a clear channel for deeper security diligence requests. | Customer diligence |
| Status page link | Implemented | Whether operational availability is surfaced through a public status mechanism. | Customer diligence |
| Security contact channel | Implemented | Whether customers know how to reach OVII for security and privacy review conversations. | Customer diligence |
* Supported for enterprise deployments.
# Current coverage includes login failures, lockouts, and selected sign-in flows; full authentication-event coverage is not yet implemented across all flows.
Security review
Need a deeper review than the public page?
Customer diligence often goes beyond a public overview. If you need privacy documentation, architecture context, or a direct security review conversation, we can route you to the right team.