How Oneward handles your data, where it runs, and what your security team can review before anything is connected.
Last updated 7 September 20261.1 Oneward, Inc. ("Oneward", "we", "us") operates an AI-native HRIS and a platform of governed HR AI agents for business customers ("Customer"). Security is a design constraint of the platform, not an add-on.
1.2 Shared responsibility. Oneward secures the platform, its infrastructure, and the controls described on this page. The Customer is responsible for its users, credentials and role assignments, the lawfulness of the data it provides and the instructions it gives, the review and approval of AI proposals, and its configuration choices (Section 14).
1.3 Items marked "Roadmap" describe current intentions, not present commitments. Oneward does not claim any certification, attestation, audit or insurance it does not hold.
2.1 The platform runs on Amazon Web Services (AWS) in two geographic regions: the European Union and the United States. Each Customer's data is hosted in one region, selected at onboarding and recorded in the Order Form, and requests are fenced to that geographic boundary. Customers headquartered in the EEA, the United Kingdom or Switzerland are hosted in the EU by default; Customers headquartered in the United States are hosted in the US by default.
2.2 Application compute runs on AWS ECS Fargate. Infrastructure is defined as code (Pulumi) and deployed through GitHub Actions with peer review and environment gating.
2.3 Development, staging and production are separate environments with separate credentials. Production data is not used in non-production environments.
2.4 Core data stores: PostgreSQL 16 (relational data), Neo4j 5 (organizational graph), Redis 7 (cache and ephemeral state), BullMQ (job queues). The application is written in Node.js 22 with strict TypeScript.
2.5 Corporate email and documents run on Google Workspace.
3.1 Customer Data at rest, including backups, remains in the Customer's selected region.
3.2 Personnel access. Oneward personnel in Germany and the United States may access Customer Data to provide support and to operate, maintain and secure the platform. Access is limited to what the task requires, logged, and covered by confidentiality obligations. Where such access constitutes an international transfer, it is covered by the Standard Contractual Clauses in our Data Processing Agreement (DPA).
3.3 AI model processing. Requests to AI model providers (Section 7) may be processed in the United States regardless of the hosting region, unless a regional endpoint has been configured for the Customer. These transfers are covered by the providers' data processing terms and Standard Contractual Clauses.
4.1 In transit: TLS 1.2 minimum, TLS 1.3 preferred, for all external connections.
4.2 At rest: AES-256 on all data stores and backups.
4.3 Sensitive fields, for example identity documents and bank details, are additionally encrypted at the application level with libsodium.
4.4 Keys are managed in AWS KMS with envelope encryption and scheduled rotation.
4.5 Roadmap: dedicated encryption keys per Customer.
5.1 Multi-factor authentication is required for all administrative access to the platform and its infrastructure.
5.2 Authorization is enforced by OpenFGA, a relationship-based access control system, at the level of individual objects and actions. Every read and write, whether by a human user or an AI agent, is checked against the same authorization model.
5.3 Oneward staff access to Customer environments follows least privilege and is logged. Roadmap: just-in-time, time-boxed access for all staff.
5.4 Audit logs record authentication events, permission changes, data access and material actions, and are retained for 12 months.
5.5 Roadmap: single sign-on (SAML) and automated user provisioning (SCIM).
6.1 The platform is multi-tenant. Every query is scoped to the Customer's tenant and every access is mediated by the authorization model in Section 5.2, so that no Customer can read or write another Customer's data.
7.1 Human in the loop. Agent actions that move money or change access rights are placed in a review queue and are not executed until a human authorized by the Customer approves them. All AI outputs are proposals; the Customer reviews and decides.
7.2 Evaluation gates. Agent capabilities that write to payroll, payment or access systems are released only after passing repeated evaluation runs against defined success thresholds, and are monitored in production.
7.3 Governed interfaces. AI agents operate only through the same governed interfaces and the same permission model as human users. In Oneward's data model, employees, contractors and AI agents are all subtypes of Worker; an agent holds scoped permissions and cannot exceed them.
7.4 Threat mitigations. Inputs from external systems and documents are treated as untrusted. Agents can call only allow-listed tools, outputs are validated before execution, and agent context is monitored for prompt injection and data exfiltration attempts.
7.5 Model providers. The platform uses models from Anthropic, OpenAI and Google, served through the providers' APIs and Google Vertex AI, under enterprise or API terms that prohibit the use of Customer Data to train the providers' models, with zero or minimal data retention where the provider offers it. Oneward does not use Customer Data to train its own models without the Customer's written consent.
7.6 Model routing. The platform may route a request to any of the providers in Section 7.5. Routing details are available on request.
7.7 No solely automated decisions. Oneward does not make decisions producing legal or similarly significant effects on individuals. Decisions remain with the Customer.
8.1 All code changes require peer review on a protected main branch.
8.2 Dependencies and container images are scanned automatically in CI.
8.3 Secrets are held in a managed secret store; no secrets are committed to source code.
8.4 Deployment credentials follow least privilege; production deployments require approval and are logged.
9.1 Vulnerabilities are triaged and remediated on a risk-prioritized basis; critical issues take precedence over planned work.
9.2 Report suspected vulnerabilities to security@oneward.com. We acknowledge reports within two business days.
9.3 Safe harbor. If you make a good-faith effort to comply with this policy during your research, we consider your research authorized, we will work with you to understand and resolve the issue, and Oneward will not pursue or recommend legal action against you for that research. Do not access, modify or exfiltrate data that is not yours, do not degrade the service, and give us reasonable time to remediate before public disclosure.
9.4 Independent penetration tests are planned at least annually, starting with the first production release.
10.1 Application and infrastructure logs are centralized, retained and monitored for anomalies, with alerting on security-relevant events. Product analytics inside the platform use PostHog (Section 13).
11.1 Encrypted backups are taken on a regular schedule and stored in the Customer's selected region.
11.2 Recovery objectives are defined in the Order Form or DPA where agreed. Restore procedures are tested on a regular schedule.
11.3 Business continuity and disaster recovery plans are maintained and reviewed at least annually.
12.1 Oneward maintains an incident response process covering detection, containment, eradication, recovery and post-incident review.
12.2 For a confirmed personal data breach affecting a Customer's data, Oneward notifies the affected Customer without undue delay and in any case within 72 hours of confirming the breach, with the information reasonably available at that time and updates as the investigation proceeds. The DPA governs the details.
13.1 Oneward uses the following subprocessors to provide the platform. We give at least 30 days' advance notice of any new or replacement subprocessor; to receive notices, email security@oneward.com with the subject "Subprocessor notices". A Customer may object on reasonable data protection grounds within the notice period; the DPA governs the consequences.
| Subprocessor | Purpose | Location |
|---|---|---|
| Amazon Web Services | Hosting, compute, storage, backups, key management | EU or USA, per Customer region |
| Anthropic | AI model inference | USA |
| OpenAI | AI model inference | USA |
| Google Cloud (Vertex AI) | AI model inference | USA or EU, per configuration |
| Google Workspace (Google LLC) | Corporate email and documents, support communications | USA |
| PostHog | Product analytics inside the platform | USA (EU hosting available) |
13.2 GitHub hosts source code and CI/CD only and does not process Customer Data.
14.1 Manage users, roles and credentials; deprovision leavers promptly.
14.2 Ensure the lawfulness of the data and instructions provided to Oneward, including notices to Workers and any required consents or other legal bases.
14.3 Review and approve AI proposals before they take effect; do not rely on outputs without human review.
14.4 Select a hosting region and configuration appropriate to the Customer's legal obligations.
15.1 The platform is designed to support Customer compliance with the GDPR, the UK GDPR, the Swiss FADP and US state privacy laws, and to support Customers' obligations as deployers under the EU AI Act (see Terms of Service, Annex B). Oneward acts as a processor (in US terms, a service provider) for Worker Data.
15.2 Certifications. Oneward holds no certifications today. SOC 2 and ISO/IEC 27001 programs are in progress. Oneward makes no certification, attestation or cyber insurance claim until it holds one.
16.1 Background checks where lawful, confidentiality agreements for all staff, security awareness training, and managed devices with disk encryption and endpoint protection.
17.1 The DPA, security questionnaire responses and further documentation are available on request from security@oneward.com. Data protection: privacy@oneward.com. Legal notices: legal@oneward.com.