Hance Consulting FZE

United Arab Emirates

Email: info@hanceconsulting.com | hello@voicase.me

Website: www.hanceconsulting.com | www.voicase.me

VoiCase Security Policy

Effective Date: 01 January 2026

Version: 2.0

1. Purpose

This Security Policy describes the measures implemented by VoiCase to protect the confidentiality, integrity, and availability of client data processed through the VoiCase platform.

This document is for informational purposes only and does not create contractual obligations beyond those agreed in applicable service agreements.

2. Security Governance

VoiCase maintains security practices appropriate to the nature of its whistleblowing and case management platform. The platform implements seven independent layers of security — edge protection, transport encryption, network isolation, identity and access management, secrets management, application-level controls, and data-at-rest encryption.

Security controls are periodically reviewed and updated based on:

• Legal and regulatory requirements
• Industry practices
• Operational risk assessments

3. Infrastructure Security

3.1 Cloud Hosting

• Infrastructure Provider: Amazon Web Services (AWS)
• Hosting Region: EU (Frankfurt, Germany) — eu-central-1
• Data residency: European Union (Frankfurt, Germany)
• AWS Managed Web Application Firewall (WAF) with five rule groups:
  • OWASP Core Rule Set (SQLi, XSS, path traversal)
  • Known Bad Inputs (Log4Shell, SSRF, RFI)
  • Auth endpoint rate limiting (300 requests / 5 minutes)
  • AI endpoint rate limiting (500 requests / 5 minutes)
  • Global rate limiting (3,000 requests / 5 minutes per IP)

VoiCase leverages AWS security architecture, physical security controls, and infrastructure-level safeguards.

3.2 Network Security

• All application services run in a private VPC with no direct public internet access
• Application containers (ECS Fargate) are deployed in private subnets with assignPublicIp: DISABLED — no public IP addresses are assigned to application tasks
• The database (Aurora PostgreSQL) is deployed in a private subnet accessible only from application container security groups — not from the internet or other services
• A three-tier security group chain enforces least-privilege network paths: ALB SG → ECS Task SG (port 3000) → Aurora SG (port 5432), using security group references rather than CIDR ranges
• Outbound internet traffic is routed through a NAT instance — application services have no inbound public IP
• S3 traffic is routed via a VPC Gateway Endpoint and never traverses the public internet

4. Data Protection Measures

4.1 Encryption

• In transit: TLS 1.3 preferred, TLS 1.2 minimum (TLS 1.0 and 1.1 are fully blocked) using AWS ELBSecurityPolicy-TLS13-1-2-2021-06. HTTP port 80 returns a 301 permanent redirect — zero plaintext traffic is permitted. All S3 storage access is additionally enforced over TLS at the bucket policy level, independent of application controls.
• Object storage: File attachments encrypted at rest using AES-256 (SSE-S3, AWS-managed keys) with versioning enabled for point-in-time recovery.
• Database: Aurora PostgreSQL encrypted at rest using AES-256 via a dedicated AWS KMS-managed key. Deletion protection is enabled.
• Secrets: All 16 application secrets stored in AWS Secrets Manager, encrypted at rest using a dedicated AWS KMS-managed key. Secrets are injected at container startup via task definition ARN references — they never appear in plaintext in API outputs, task definitions, or deployment logs.
• Container images: ECR images encrypted at rest (AES-256), tagged with immutable SHA digests, and scanned for vulnerabilities automatically on push.

4.2 Access Controls

• Role-based access control (RBAC) with four permission tiers (admin, manager, member, viewer) and 16 granular per-user permission flag overrides
• Department-scoped case visibility restricts which cases each user can access within their organization
• Multi-factor authentication (MFA) enforced for administrative access, with Passkey / WebAuthn support
• Principle of least privilege applied across all IAM roles, security groups, and application permissions
• Logical separation of client environments enforced at the database layer via PostgreSQL Row-Level Security (RLS) — cross-tenant data access is not possible even with a valid session token

4.3 Authentication

User authentication uses JWT tokens with MFA enforcement in application middleware. Administrative access requires strong authentication mechanisms and restricted access rights. Database authentication uses IAM token-based access (no static passwords). Deployment pipelines use short-lived OIDC tokens — no long-lived cloud credentials are stored in source repositories or CI/CD configuration.

5. Application Security

VoiCase implements application-level safeguards including:

• Centralized API security through BaseApiHandler, which validates organization identity, user role and permission flags, and input UUIDs on every single endpoint
• JWT authentication with MFA enforcement in application middleware
• Session management controls
• Typed security audit logger capturing all authorization successes, failures, and data changes
• Controlled access to administrative interfaces — super-admin pages gated by verified owner email
• A dedicated DATA_RETENTION_SECRET required for all destructive data operations
• AWS Managed WAF rules aligned with OWASP Top 10 (SQL injection, XSS, SSRF, known CVEs)
• hCaptcha bot prevention on all public submission endpoints
• Strict HTTP security headers on every response: HSTS, Content-Security-Policy, X-Frame-Options (DENY), X-Content-Type-Options, Referrer-Policy, Permissions-Policy
• S3 file attachments accessible only via presigned URLs with 24-hour TTL — never publicly exposed

Security testing and updates are conducted periodically as appropriate to the service.

6. Secrets Management

VoiCase stores 16 application secrets in AWS Secrets Manager under a dedicated prefix. Secrets are injected into application containers at startup via task definition ARN references. This ensures:

• Zero plaintext secrets in ECS task definitions or DescribeTaskDefinition API output
• No secrets stored in source code, environment variable arrays, or CI/CD configuration
• All secrets encrypted at rest with a dedicated AWS KMS-managed key
• CI/CD pipelines authenticate to AWS via OIDC federation — no long-lived credentials stored anywhere
• IAM roles scoped to least privilege: the execution role can only read secrets under the voicase/ prefix

7. Data Retention and Deletion

• Default retention period: 30 days unless configured otherwise by the client.
• Clients may manage retention settings within the platform.
• All destructive data operations require a dedicated DATA_RETENTION_SECRET — preventing accidental or unauthorized deletion.
• Upon contract termination and written request, data will be deleted or returned, subject to backup retention policies.
• Automated database backups are retained for a minimum of 7 days (Aurora PostgreSQL) with deletion protection enabled.
• Object versioning is enabled on file storage, providing point-in-time data recovery capabilities.
• Secure backups are maintained in accordance with operational continuity requirements.

8. Monitoring and Incident Response

VoiCase maintains monitoring mechanisms to detect potential security incidents, including:

• 24/7 infrastructure monitoring across all AWS services
• Typed security audit logging for all authentication, authorization, and data access events
• Application health checks verified before the load balancer routes traffic to new deployments

In the event of a confirmed personal data breach affecting client data:

• Clients will be notified without undue delay.
• Where feasible, notification will occur within 72 hours of confirmation.
• Notification may be provided in phases as additional information becomes available.

Clients remain responsible for regulatory notifications unless otherwise agreed.

9. CI/CD and Deployment Security

VoiCase employs a zero-trust deployment pipeline:

• CI/CD pipelines (GitHub Actions) authenticate to AWS via OIDC federation — no long-lived credentials are stored in source code, CI configuration, or environment variables
• The CI/CD IAM role is scoped to specific ECR repositories (push only), specific ECS cluster/service ARNs, and can only pass the designated execution and task roles
• Container images are pushed to Amazon ECR with immutable SHA tags (no mutable :latest tags) and are automatically scanned for vulnerabilities on push
• Application secrets are stripped from environment variable arrays during deployment and injected as Secrets Manager ARN references — ensuring zero plaintext in any API output
• New tasks are deployed in private subnets with no public IP and must pass health checks before the load balancer routes traffic

10. Personnel Security

Access to client data is restricted to authorized personnel on a need-to-know basis.

Personnel with system access are subject to:

• Confidentiality obligations
• Access control policies

11. Sub-Processors

VoiCase may engage infrastructure and technical service providers necessary to operate the platform.

Such providers are contractually bound to maintain appropriate data protection and security safeguards.

12. Client Responsibilities

Clients are responsible for:

• Determining lawful basis for data processed through the platform
• Configuring retention settings appropriately
• Managing user access within their organization
• Protecting their own credentials

13. Continuous Improvement

Security practices are periodically reviewed and may evolve in response to:

• Regulatory developments
• Infrastructure updates
• Operational risk assessments

The most current version of this Security Policy will be available on the VoiCase website.