Version 1 Last updated: April 29, 2026
This document describes the technical and organisational security measures implemented by Bantero AB (“Bantero”) pursuant to Article 32 GDPR to protect Personal Data processed through the OKRnest service, as referenced in Section 5 and Annex 2 of the Data Processing Agreement.
1. Encryption
In transit — All data transmitted between users and the service is encrypted using TLS 1.2 or higher. Unencrypted connections are rejected or automatically redirected to encrypted channels. Strict Transport Security (HSTS) is enforced with preload.
At rest — All persistent data stores, including the primary database, file storage, and stored secrets, are encrypted at rest using AES-256 encryption. Backups inherit the encryption settings of the source data.
Secrets — Application secrets and credentials are stored in a dedicated secrets management service and injected at runtime. Secrets are never stored in source code or container images.
2. Access Control
Infrastructure access — All administrative accounts are protected with multi-factor authentication (MFA). Infrastructure is managed through Infrastructure as Code with version-controlled change processes. There is no direct SSH access to production systems; administrative access is performed through managed, auditable channels only.
Application access — Users authenticate via email and password. Passwords are hashed using an industry-standard, salted algorithm and are never stored in plaintext. A minimum password length of 10 characters is enforced, along with checks against common passwords and user attribute similarity. Authentication sessions use short-lived tokens with longer-lived refresh tokens, stored in secure, HTTP-only cookies. Sessions are invalidated on logout and refresh tokens are rotated and blacklisted on each use. Brute-force protection is in place with account lockout after repeated failed attempts, and rate limiting is applied on authentication and other sensitive endpoints.
Multi-factor authentication — MFA is required for all Bantero personnel accessing internal administrative systems and is enforced on every login. For end users of the service, MFA is available and can be made mandatory per organisation by the Customer. Recovery codes are provided as a fallback.
Role-based access control — The application enforces role-based permissions (Owner, Admin, Member). Users can only access data within the organisations they have been granted access to.
Personnel access — Access to production systems and Personal Data is limited to authorised personnel on a need-to-know basis.
Support and customer success access — Authorised Bantero personnel may access Customer accounts, including through account impersonation, for the purposes of customer support, troubleshooting, and customer success activities. Such access is subject to the following controls:
- Access is authenticated and requires the personnel’s own credentials;
- All account access events, including impersonation sessions, are logged with actor identity, timestamp, and duration; and
- Access is limited in duration to what is necessary for the purpose.
3. Network Security
Architecture — The service is hosted on Amazon Web Services (AWS) in the EU (Frankfurt, eu-central-1). The database and internal services are placed in private network segments with no public internet exposure. Outbound connectivity from application components is restricted to only the external services required for operation.
Firewalls — Network-level access controls restrict inbound traffic to only the necessary ports and sources. Each infrastructure component has its own firewall rules following the principle of least access.
Web Application Firewall — A web application firewall is deployed in front of all public-facing endpoints, providing protection against common threats including SQL injection, cross-site scripting, known bad inputs, and automated bot traffic.
DDoS protection — The infrastructure includes baseline DDoS protection and edge-level traffic absorption through a content delivery network.
Security headers — The application enforces industry-standard security headers to protect against common browser-based attacks.
4. Monitoring and Logging
Application monitoring — Application errors and performance anomalies are monitored in real time with automated alerting.
Infrastructure monitoring — Infrastructure health, resource utilisation, and database performance metrics are collected continuously.
Logging — All API requests are logged with request metadata, user context, and response status. Authentication events (successful logins, failed attempts, lockouts, MFA events) are logged separately. An application-level audit trail records data mutations with actor, timestamp, and change details.
WAF logging — Web application firewall metrics and sampled requests are collected for security analysis.
Log retention — Logs are retained for varying periods depending on their type and purpose, in accordance with applicable legal and operational requirements.
5. Backup and Disaster Recovery
Database backups — Automated daily backups are performed with a retention period of 30 days. Point-in-time recovery is available within the retention window. All backups are encrypted at rest.
Application resilience — The application runs with automatic health checks, container restart on failure, automatic scaling based on load, and deployment safeguards that automatically roll back failed releases.
Infrastructure reconstruction — All infrastructure is defined as code, enabling full environment reconstruction from configuration and the most recent database backup.
Recovery objectives:
- RPO (Recovery Point Objective): Up to 24 hours, with point-in-time recovery available within that window.
- RTO (Recovery Time Objective): Target is to restore service within hours of a major incident.
6. Vulnerability Management
Dependency scanning — Automated vulnerability scanning is enabled on all code repositories, detecting and proposing updates for known vulnerabilities in third-party dependencies.
Patching — Managed infrastructure services receive patches from the provider. Application containers are rebuilt and updated as part of the regular development and deployment cycle.
Input validation — All user input is validated and sanitised before processing. Parameterised queries are used for all database operations to prevent injection attacks.
Secure development — All code changes are tracked through version control. Production deployments are automated through CI/CD pipelines.
7. Incident Response
Upon detection of a suspected security incident, Bantero follows a structured response process:
- Acknowledge — within 48 hours of detection.
- Investigate — determine scope, cause, and affected data.
- Contain — limit impact through credential rotation, access revocation, or component isolation as appropriate.
- Notify — if the incident constitutes a Personal Data Breach, the Customer is notified within 48 hours in accordance with the DPA.
- Remediate — address root cause and implement preventive measures.
- Document — maintain a post-incident record.
Breach notifications include the nature of the breach, categories of data affected, likely consequences, and measures taken.
8. Sub-processor Security
Bantero requires that all sub-processors implement appropriate technical and organisational measures. Sub-processors are evaluated for adequate security and data protection compliance before engagement. The current list is maintained in the separate Sub-processor List.
9. Physical Security
All infrastructure is hosted on AWS, which maintains comprehensive physical security controls, including 24/7 security personnel, multi-factor facility access, environmental controls, and power redundancy. AWS holds SOC 2 Type II and ISO 27001 certifications. Bantero does not operate its own data centres or physical servers.
10. Data Separation
Customer data is logically separated at the application level. Each organisation’s data is isolated through application-enforced tenant boundaries, ensuring that users of one organisation cannot access data belonging to another.
11. Data Deletion
Upon termination of a Customer’s account, data is handled in accordance with the DPA:
- Production — Customer Data is deleted from production systems within 30 days of termination.
- Backups — Purged within 90 days of production deletion, unless retention is required by applicable law.
Deletion covers all organisation-related data. Audit logs are retained independently to preserve the integrity of the audit trail.
12. Review and Updates
Bantero reviews these measures periodically and updates them as needed to reflect changes in technology, threats, and regulatory requirements. Updates will not materially reduce the overall level of protection.
This document is referenced by the OKRnest Data Processing Agreement (Annex 2) and is available at okrnest.com/trust-center/technical-and-organisational-measures.