Security Policy

Document ID: SURWAYR-SEC-v1.1
Effective date: 28 March 2026
Last reviewed: 28 March 2026
Owner: CTO / Security lead
Reference standard: ISO/IEC 27001:2022 controls (with Annex A references)

Hungarian original (HU): Download the authoritative PDF (HU)

1. Purpose and scope

This policy sets out information security governance for the SURWAY’R platform in line with ISO/IEC 27001:2022. It applies to all employees, contractors, and processors with access to SURWAY’R systems.

Framework references: - ISO/IEC 27001:2022 — Annex A controls (A.5–A.8) - GDPR Art. 32 — appropriate technical and organisational measures - ENISA Cloud Security Guidelines

2. Organisational and personnel security (ISO 27001 A.5, A.6)

2.1 Security responsibilities

The CTO is responsible for maintaining the information security management system.
All employees and contractors sign a confidentiality agreement (NDA) at onboarding.
Access to sensitive systems (database, admin panel) is granted only on documented need.

2.2 Background checks

Reference checks for new staff with system access (ISO 27001 A.6.1).
Contractors: security requirements are contractually binding.

2.3 Security awareness

Mandatory annual security awareness training for all relevant staff (ISO 27001 A.6.3).
Phishing simulations at least once per year.

3. Access management (ISO 27001 A.5.15–A.5.18)

3.1 Role-based access control (RBAC)

SURWAY’R applies least privilege. Defined roles:

Role	Systems	Level
Admin	All systems	Full
Developer	Application code, staging DB	Read + write
Support	User accounts (limited)	Read
Read-only	Analytics, dashboards	Read only

3.2 Access reviews

Quarterly access review (ISO 27001 A.5.18): all accounts and permissions manually verified.
Departed employees and contractors: access revoked on termination day, at the latest within 24 hours.
Quarterly review logs for admin access; available to DPO and legal.

3.3 Multi-factor authentication (MFA)

MFA (TOTP or hardware key) is mandatory for all admin and developer accounts (ISO 27001 A.8.5).
No exceptions; accounts without MFA are disabled.

3.4 Privileged access management (PAM)

Database and server root/admin access only via time-limited elevation (just-in-time).
Privileged actions are always logged (who, when, what).
Shared root passwords are not used; service accounts and API keys are used instead.

4. Cryptography and key management (ISO 27001 A.8.24)

4.1 Encryption requirements

In transit: TLS 1.2 minimum (TLS 1.3 preferred); SSLv3, TLS 1.0/1.1 prohibited.
At rest (application-layer sensitive fields): TOTP secrets, AI API keys, and webhook signing secrets are stored using AES-256-GCM (AEAD); 96-bit nonce from a CSPRNG; additional authenticated data (AAD) for context binding (surwayr:v1). Nonce collision probability is negligible. Full-database volume encryption is understood at the infrastructure (Hetzner) layer.
Passwords: Argon2id (RFC 9106 recommended parameters: memory_cost=65536 (64 MiB), time_cost=3, parallelism=4). Existing bcrypt hashes remain valid; on successful sign-in the system re-hashes them to Argon2id (verify_and_update). Parameters may be adjusted based on hardware evolution.
Algorithms require CTO approval; weak algorithms (e.g. MD5, SHA-1 for security use) are prohibited.
Memory and logs: Sensitive values are handled carefully in memory and are not written to application logs.

4.2 Cryptographic key lifecycle (ISO 27001 A.8.24)

Key type	Generation	Storage	Rotation	Max lifetime
`ENCRYPTION_KEY` (field encryption)	CSPRNG (64 hex chars = 32 bytes)	Only environment variable or secret manager (Vault); not in source control	Annually or on compromise	Ongoing
External API keys	CSPRNG	Encrypted secrets store (e.g. Vault / env)	Every 90 days or on compromise	1 year
Database encryption keys	KMS (Hetzner / self-managed)	In KMS	Annually	Ongoing
Session tokens	CSPRNG	HttpOnly, Secure cookie	On session end	Default 24 h (authenticated), `SESSION_MAX_AGE` configurable
SSL/TLS certificates	Let’s Encrypt / CA	ACME automation	90 days (auto)	90 days
Backup encryption keys	CSPRNG	Offline, segregated storage	Annually	Ongoing

On key compromise: immediate rotation, incident response, user notification as required.

5. Audit logging (ISO 27001 A.8.15)

5.1 Scope

The following must be logged:

Category	Fields	Retention
Authentication (sign-in, sign-out, 2FA)	User ID, IP, timestamp, success/failure	12 months
Admin actions	Admin ID, action, resource, timestamp	24 months
Database access (SELECT/INSERT/UPDATE/DELETE)	Query type, table, user, timestamp	12 months
API calls	Endpoint, method, user/API key, status, IP	6 months
Exports (SPSS, CSV, JSON)	User ID, survey ID, file size, timestamp	12 months
Security incidents	All of the above + context	36 months

5.2 Integrity and protection

Logs are append-only; modification is not allowed.
Logs are replicated to separate storage (isolated from the main application).
Integrity checks (e.g. HMAC SHA-256).
Read-only access to logs for designated roles; the application cannot delete logs.

5.3 Alerts

Automated alerts for: repeated failed sign-ins, privileged admin actions, large exports, unusual DB query patterns.

6. Physical and infrastructure security (ISO 27001 A.7)

6.1 Cloud infrastructure

The application runs on Hetzner Online GmbH servers (Germany, EU), ISO 27001 certified data centres.
SURWAY’R staff have no physical access to servers.

6.2 Network segmentation

Production separated from dev/test.
Database servers are not publicly reachable; application-only access via VPN/private network.
Incoming traffic behind a WAF (Web Application Firewall).

6.3 Configuration management (ISO 27001 A.8.9)

Application infrastructure is versioned and reproducible via Dockerfile and docker-compose; changes go through code review (PR). Dedicated IaC (e.g. Terraform) is a roadmap item.
Default passwords and defaults are always overridden.

7. Vulnerability management (ISO 27001 A.8.8)

7.1 Patch management

OS and dependency updates: critical vulnerabilities within 48 hours; others on a monthly cadence.
Automated vulnerability scanning in CI/CD: pip-audit (Python) and npm audit (JavaScript) on main/develop pushes and weekly schedule (.github/workflows/security-audit.yml). Dependabot / Snyk is a roadmap item.

7.2 Penetration tests

Annual external penetration test (minimum once per year; white-box preferred).
Findings tracked in a remediation register.

7.3 Coordinated disclosure

The Vulnerability Disclosure Policy (SURWAYR-VDP-v1.0) describes how to report security issues responsibly at security@surwayr.com.

8. Business continuity and disaster recovery (ISO 27001 A.5.29, A.5.30)

Metric	Target	Current
RTO	4 hours	[to be measured]
RPO	1 hour	[to be measured]
Backup frequency	Daily incremental + weekly full	Configured
Backup testing	Quarterly full restore test	Planned
Data centre redundancy	At least one geo-replicated backup	Planned

9. Compliance and auditability

9.1 Internal audit

Annual internal audit of compliance with this policy.
Findings and corrective actions are documented.

9.2 External certifications (roadmap)

Certification	Status	Target
ISO 27001:2022	Not certified (controls implemented)	Q4 2026
SOC 2 Type II	Not certified	2027

A DPIA is required before high-risk processing, in particular: - Automated decision-making - Large-scale special categories of data - New surveillance/profiling features

10. Policy review

This policy is reviewed annually or after material organisational or technical changes. The CTO is responsible; management approves.

Incident Response Plan (SURWAYR-IRP-v1.0)
Privacy Policy (SURWAYR-PP-v1.0)
Data Processing Agreement (SURWAYR-DPA-v1.0)
Vulnerability Disclosure Policy (SURWAYR-VDP-v1.0)
DSR Policy (SURWAYR-DSR-v1.0)