Personal data stored in Amazon RDS (Aurora PostgreSQL) is encrypted at rest.
Encryption is implemented using AWS Key Management Service (KMS).
AWS-managed KMS keys are used for database encryption. Key management and rotation are handled by AWS.
Data stored in Amazon S3 is encrypted using Server-Side Encryption with Amazon S3 managed keys (SSE-S3) with AES-256 encryption.
Personal data is not intentionally stored on local developer endpoints as part of normal operations.
1.2 Data in Transit
All external communications between users and the application backend are encrypted using HTTPS/TLS.
Internal service communications occur within AWS-controlled networking environments.
1.3 Secrets Management
Application credentials (e.g., database passwords, API keys) are stored using AWS secrets management mechanisms.
Access to secrets is restricted using AWS Identity and Access Management (IAM) policies.
1.4 Data Identification Structure
Subjects are referenced internally using system-generated unique identifiers.
Personal attributes (if collected) are stored in the application database and linked to sessions and trials via these identifiers.
Identifying information and associated session/trial data are accessible only through authenticated and authorised application access.
Data is logically structured within the application to limit direct exposure of identifying information.
2. Access Control, Authentication and Authorisation
2.1 AWS Infrastructure Access
Access to AWS infrastructure is restricted to authorised personnel only.
Current access structure: 2 Administrators, 4 Engineers, 2 Contractors.
Multi-Factor Authentication (MFA) is enforced for all AWS accounts.
2.2 Role-Based Access
Engineers are granted: PowerUserAccess, IAMReadOnlyAccess, AWSBillingReadOnlyAccess, AllowUserMFASetup.
Contractors are granted: AdministratorAccess-Amplify (scoped to Amplify resources), CloudWatchReadOnlyAccess.
Access is assigned through AWS Identity and Access Management (IAM) roles and policies. Administrative privileges are restricted to a limited number of accounts.
Administrative access is limited to authorised personnel involved in sales, development, and system maintenance.
2.4 Platform User Authentication
End users authenticate using email address and password.
Two-factor authentication (2FA) is implemented via email-based verification codes.
Authentication is required to access any personal data within the platform.
2.5 Principle of Least Privilege
Access rights are assigned based on role and operational necessity.
Infrastructure and administrative access are restricted to personnel requiring such access for system operation and maintenance.
MFA is enforced at the infrastructure level.
3. Logging, Monitoring and Incident Response
3.1 Logging and Monitoring
Application and infrastructure metrics are monitored using AWS CloudWatch.
CloudWatch alarms are configured for infrastructure scaling and capacity monitoring.
Logging is enabled for selected services where operationally required.
Logs do not intentionally contain personal data.
3.2 Security Monitoring
Access to infrastructure is restricted via IAM roles and Multi-Factor Authentication (MFA).
3.3 Incident Response
In the event of a suspected security incident, access credentials may be revoked or rotated and infrastructure access reviewed.
Security incidents would be assessed by the administrative team to determine scope and impact.
Where required under applicable data protection laws, affected controllers and/or supervisory authorities would be notified within legally mandated timeframes.
4. Availability, Resilience and Backup
4.1 Infrastructure Architecture
The application is hosted on Amazon Web Services (AWS).
A load balancer distributes incoming traffic to application services.
Core API services run on a single primary instance.
Certain worker services are partially managed via Auto Scaling Groups to support workload scaling.
Database infrastructure (Amazon Aurora PostgreSQL) is deployed in a single Availability Zone.
4.2 Database Backup
Automated backups are enabled for Amazon RDS (Aurora PostgreSQL).
Backup retention is configured for 7 days.
Backups are stored within AWS-managed infrastructure.
4.3 Object Storage
Personal data stored in Amazon S3 is encrypted using Server-Side Encryption (SSE-S3).
S3 object versioning is not enabled.
4.4 Disaster Recovery and Recovery Objectives
The infrastructure is deployed in a single AWS region and single Availability Zone.
In the event of service disruption, recovery would rely on restoring services and database backups within AWS.
5. Data Minimisation, Retention and Deletion
5.1 Data Minimisation
Personal data collected is limited to what is necessary to provide the service.
Subjects are referenced internally using system-generated identifiers.
Users can manage and delete their accounts at any time.
5.2 Data Retention
Database records containing personal data are retained only as long as required to provide the service or as required by contract or law.
Backups are maintained with a retention period of 7 days.
S3 objects storing personal data are retained as needed for service operation.
An internal data retention policy governs the retention and deletion of personal data after contract termination.
5.3 Data Deletion / Erasure
Upon request by a customer or user, all personal data can be deleted from database records and S3 storage.
Backups are automatically purged according to the retention schedule (7 days).
Data deletion procedures are applied consistently in accordance with the internal retention and deletion policy.
5.4 Accountability
Model Health maintains internal policies to ensure data minimisation, controlled retention, and timely deletion of personal data in line with GDPR obligations.
6. Monitoring, Testing, and Evaluation of Technical and Organisational Measures
6.1 Monitoring
AWS CloudWatch is used to monitor infrastructure metrics, including auto-scaling, resource utilisation, and system availability.
CloudWatch alarms are configured to alert the team when thresholds for system resources or service availability are exceeded.
Logs from selected services are collected for operational purposes; these logs do not intentionally contain personal data.
6.2 Testing and Evaluation
No formal, scheduled penetration testing or vulnerability scanning is currently performed on production systems.
Backup restoration procedures have not been formally tested on a scheduled basis.
System and process security measures are evaluated informally by the development team during routine maintenance and updates.
6.3 Improvement of Measures
Security, access control, and backup procedures are updated periodically as part of ongoing infrastructure and platform maintenance.
Any identified operational issues or incidents are addressed promptly to maintain system integrity and availability.
