Enterprise Security Measures and Trust Framework

1. Security Model and Shared Responsibility

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

For enterprise deployments, the decision should be translated into a RACI matrix, verifiable evidence, acceptance criteria, technical controls and periodic review; exceptions must be approved, reasoned, time-limited and traceable.

2. Security Governance

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

In healthcare or multi-centre projects, the requirement should be linked to the protocol, decision record, DPIA or security file where relevant, avoiding any assumption that a technical configuration replaces legal or scientific assessment.

3. Identity, Authentication and 2FA

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Two-factor authentication reduces credential-compromise risk and may be made mandatory for roles selected by policy. The Superadmin controls the relevant policy; recovery, reset and disablement must be logged and protected by controls commensurate with the access being restored.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

Compliance is continuous: changes to purpose, data, suppliers, engines, hosting, integrations or law require impact assessment and, where needed, updates to contracts, controls, instructions and documentation.

4. Authorisation, RBAC and Least Privilege

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Permissions are assigned by role and organisational scope under least privilege. They should be periodically reviewed and updated when duties change; high-impact operations, exports and administrative functions are restricted to expressly authorised roles.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

UESE retains evidence proportionate to function and risk. The customer organisation remains responsible for its authorisations, protocols, legal bases and healthcare or scientific decisions beyond the service scope entrusted to UESE.

5. Logical Segregation Between Organisations

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Multi-tenant separation is enforced by applying organisational context to application queries and operations. Customers must avoid configurations that enable inappropriate project sharing; dedicated or on-premise instances may be considered where stronger isolation is required.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

For enterprise deployments, the decision should be translated into a RACI matrix, verifiable evidence, acceptance criteria, technical controls and periodic review; exceptions must be approved, reasoned, time-limited and traceable.

6. Encryption and Secret Management

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Credentials and application secrets must be encrypted or hashed with algorithms appropriate to their purpose. Data in transit requires TLS; checksums and integrity chains can support evidential integrity, but do not replace backups, access control or scientific validation.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

In healthcare or multi-centre projects, the requirement should be linked to the protocol, decision record, DPIA or security file where relevant, avoiding any assumption that a technical configuration replaces legal or scientific assessment.

7. Genomic Data and Storage Protection

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Health and genetic data are special categories under GDPR Article 9. The controller must identify an Article 6 legal basis and an Article 9 condition, assess applicable health and research law and implement appropriate safeguards; pseudonymisation reduces risk but does not automatically make data anonymous.

FASTQ, BAM/CRAM and large datasets should not pass through ordinary PHP shared-hosting uploads. The platform governs metadata, references, checksums and permissions, while large payloads belong in authorised storage under territorial and contractual conditions compatible with the project.

Compliance is continuous: changes to purpose, data, suppliers, engines, hosting, integrations or law require impact assessment and, where needed, updates to contracts, controls, instructions and documentation.

8. Integrity, Hashing and Traceability

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Credentials and application secrets must be encrypted or hashed with algorithms appropriate to their purpose. Data in transit requires TLS; checksums and integrity chains can support evidential integrity, but do not replace backups, access control or scientific validation.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

UESE retains evidence proportionate to function and risk. The customer organisation remains responsible for its authorisations, protocols, legal bases and healthcare or scientific decisions beyond the service scope entrusted to UESE.

9. Event Logging and Audit

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Technical access data may be processed for security, troubleshooting, abuse prevention and accountability. Logging must remain proportionate: application and security logs should not contain genomic sequences, medical reports or sensitive payloads unless strictly necessary and authorised.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

For enterprise deployments, the decision should be translated into a RACI matrix, verifiable evidence, acceptance criteria, technical controls and periodic review; exceptions must be approved, reasoned, time-limited and traceable.

10. Application Security and Development

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

The development lifecycle includes dependency control, change review, testing and update management. Vulnerabilities are assessed according to severity, exposure and impact; critical fixes may require urgent maintenance and targeted communication to affected customers.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

In healthcare or multi-centre projects, the requirement should be linked to the protocol, decision record, DPIA or security file where relevant, avoiding any assumption that a technical configuration replaces legal or scientific assessment.

11. Vulnerability Management and Patching

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

The development lifecycle includes dependency control, change review, testing and update management. Vulnerabilities are assessed according to severity, exposure and impact; critical fixes may require urgent maintenance and targeted communication to affected customers.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

Compliance is continuous: changes to purpose, data, suppliers, engines, hosting, integrations or law require impact assessment and, where needed, updates to contracts, controls, instructions and documentation.

12. Integration and API Security

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

UESE retains evidence proportionate to function and risk. The customer organisation remains responsible for its authorisations, protocols, legal bases and healthcare or scientific decisions beyond the service scope entrusted to UESE.

13. Backup, Restore and Resilience

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Application backups should be encrypted, tested and held separately from the primary environment. RPO and RTO are not implicit software characteristics but contractual objectives dependent on hosting and continuity architecture; restoration must include integrity and functional checks before reopening the service.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

For enterprise deployments, the decision should be translated into a RACI matrix, verifiable evidence, acceptance criteria, technical controls and periodic review; exceptions must be approved, reasoned, time-limited and traceable.

14. Logging, Monitoring and Incident Response

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Technical access data may be processed for security, troubleshooting, abuse prevention and accountability. Logging must remain proportionate: application and security logs should not contain genomic sequences, medical reports or sensitive payloads unless strictly necessary and authorised.

Events are classified by severity and impact, contained and documented. Where UESE acts as processor it notifies the controller without undue delay after becoming aware of a personal data breach and provides available information for GDPR Articles 33 and 34 assessments; regulatory notifications remain with the competent party.

Requests are prioritised by impact and urgency. Response time measures acknowledgement and engagement, not necessarily resolution; critical priorities require defined escalation channels, contacts and minimum diagnostic information.

In healthcare or multi-centre projects, the requirement should be linked to the protocol, decision record, DPIA or security file where relevant, avoiding any assumption that a technical configuration replaces legal or scientific assessment.

15. Supplier and Supply-Chain Security

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

Compliance is continuous: changes to purpose, data, suppliers, engines, hosting, integrations or law require impact assessment and, where needed, updates to contracts, controls, instructions and documentation.

16. Administrative Access and Privileged Operations

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

UESE retains evidence proportionate to function and risk. The customer organisation remains responsible for its authorisations, protocols, legal bases and healthcare or scientific decisions beyond the service scope entrusted to UESE.

17. Testing, Assurance and Continuous Improvement

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

For enterprise deployments, the decision should be translated into a RACI matrix, verifiable evidence, acceptance criteria, technical controls and periodic review; exceptions must be approved, reasoned, time-limited and traceable.

18. Limits of this Public Statement and Customer Documentation

UESE applies a defence-in-depth security model with organisational, application and infrastructure controls proportionate to risk. Actual security also depends on hosting, configuration, integrations, federated identities, endpoints, customer procedures and suppliers; security is therefore a shared responsibility that must be documented in the project-specific security plan.

Documentation is version controlled and may be updated to reflect technical, scientific or regulatory change. Databases imported by the customer remain subject to the rights and restrictions applicable to their source; the existence of an import feature does not grant UESE rights over the content or guarantee that the source may lawfully be reused.

Controls should be reviewed in light of threats, vulnerabilities, incidents and architectural change. Organisational attestations or certifications must not be presented as automatic certification of the product or the customer environment.

In healthcare or multi-centre projects, the requirement should be linked to the protocol, decision record, DPIA or security file where relevant, avoiding any assumption that a technical configuration replaces legal or scientific assessment.