| Organisational controls (A.5) |
| 5.1 | Policies for information security | Internal security standards and review records are maintained. A formal, approved policy set is being written. | Partial |
| 5.2 | Roles and responsibilities | Security is owned by platform engineering. Staff roles (support, moderation, development, analytics) have role-scoped permissions in the staff console. | Partial |
| 5.7 | Threat intelligence | Community threat feeds and blocklist monitoring feed automated blocking of known malicious sources. | Implemented |
| 5.15 | Access control | Role-based access control. The staff console enforces per-section view and edit rights on the server; the most sensitive actions are limited to named administrators. | Implemented |
| 5.17 | Authentication information | Passwords are hashed with bcrypt (cost 12). New passwords are checked against known breach corpora using a k-anonymity lookup, and weak passwords are rejected. | Implemented |
| 5.18 | Access rights | Staff access is granted per role. Periodic access reviews are being formalised. | Partial |
| 5.19–5.22 | Supplier relationships | All subprocessors are listed on this page. A security review of each supplier's terms is in progress. | Partial |
| 5.24–5.27 | Incident management | Incidents are triaged, contained and reviewed, with public notes below. A written incident response plan is in progress. | Partial |
| 5.29–5.30 | Continuity and ICT readiness | Daily database backups with access limited to administrators. Encrypted off-site copies are being added. | Partial |
| 5.33 | Protection of records | Administrative actions in the staff console are recorded in an audit log. | Implemented |
| 5.34 | Privacy and protection of PII | Data minimisation; every user can export their data and delete their account. A full record of processing activities is in progress. | Partial |
| 5.35–5.36 | Independent review and compliance | Internal security reviews and penetration tests were carried out in August and September 2026. No external certification audit has taken place yet. | Partial |
| People controls (A.6) |
| 6.3 | Security awareness and training | Security guidance for staff is being prepared. | In progress |
| 6.8 | Security event reporting | Staff and users report security events to security@strinovahub.com or through the public bug bounty. | Implemented |
| Physical controls (A.7) |
| 7.1–7.14 | Physical and environmental security | Provided by our hosting provider, Hetzner Online GmbH. See the provider's ISO/IEC 27001 certificate for its scope. | Implemented |
| Technological controls (A.8) |
| 8.2 | Privileged access rights | Administrative access is limited to a small set of named accounts. Mandatory multi-factor authentication for every privileged interface is being rolled out. | Partial |
| 8.3 | Information access restriction | Authorisation is checked on the server for every endpoint, including per-object ownership checks. | Implemented |
| 8.5 | Secure authentication | TOTP two-factor authentication and one-time codes; sessions bound to the device and revocable; lockout after repeated failures; httpOnly, Secure session cookies with CSRF protection. | Implemented |
| 8.7 | Protection against malware | Uploads are validated by content signature and screened by automated moderation. Server-side malware scanning is in progress. | Partial |
| 8.8 | Management of technical vulnerabilities | Dependencies are audited regularly. The web app and staff console have no known vulnerable packages; the remaining backend dependency upgrades are scheduled. | Partial |
| 8.9 | Configuration management | The application runs in a hardened container: non-root, read-only filesystem, dropped capabilities and resource limits. Host hardening is in progress. | Partial |
| 8.12 | Data leakage prevention | Personal data is redacted from application logs, and backup files are readable by administrators only. | Implemented |
| 8.15–8.16 | Logging and monitoring | Centralised logs, metrics and alerting; automated bot and abuse scoring with rate limits; a public status page. | Implemented |
| 8.20–8.21 | Network security | All web traffic passes a reverse proxy with rate limiting and bot filtering. Restricting every management interface to private networks is in progress. | In progress |
| 8.22 | Segregation of networks | Application containers run on isolated internal networks, and databases are not reachable from the internet. Further segmentation of internal services is in progress. | Partial |
| 8.24 | Use of cryptography | TLS 1.2 and 1.3 only, with HSTS (preload). Internal tokens are encrypted with AES-GCM. Email is signed with DKIM and protected by SPF and DMARC. | Implemented |
| 8.26–8.28 | Application security and secure coding | Every API validates its input; HTML is sanitised; Content Security Policy with Trusted Types; parameterised database access; CSRF tokens; SSRF guards on outbound requests. | Implemented |
| 8.29 | Security testing | Internal audits and penetration tests, plus a public bug bounty. | Implemented |
| 8.31 | Separation of environments | Development and production run as separate instances with separate databases. Separate infrastructure for development is in progress. | In progress |
| 8.32 | Change management | All changes are version-controlled. Production releases need explicit approval, and every database migration is backed up before it is applied. | Implemented |