ArcaScience Security Architecture: A Comprehensive Technical Overview

1. Introduction and Security Philosophy

The pharmaceutical industry demands the highest standards of data security and regulatory compliance. Clinical trial data, adverse event reports, proprietary analytical models, and regulatory submission content represent some of the most sensitive information in any industry. A breach or loss of integrity in this data can have consequences ranging from competitive damage to direct harm to patient safety.

ArcaScience's security philosophy is built on four foundational principles:

• Defense in depth: No single security control is relied upon in isolation. Multiple overlapping layers of protection ensure that the compromise of any single control does not result in unauthorized access to sensitive data.
• Zero trust architecture: Every access request is authenticated, authorized, and encrypted, regardless of the requester's location within or outside the network perimeter. We assume breach and verify explicitly at every layer.
• Least privilege: Users, services, and system components are granted only the minimum permissions necessary to perform their intended functions. Permissions are reviewed quarterly and automatically revoked upon role changes.
• Security by design: Security is not an afterthought but an integral part of every stage of our software development lifecycle, from requirements gathering and architecture design through coding, testing, deployment, and operations.

These principles inform every architectural decision, operational process, and organizational practice described in this document. Our security program is overseen by a dedicated Chief Information Security Officer (CISO) who reports directly to the CEO, ensuring that security considerations receive appropriate executive attention and resource allocation.

1.1 Security Governance

ArcaScience maintains a formal Information Security Management System (ISMS) governed by a cross-functional Security Steering Committee that meets monthly. The committee includes representatives from Engineering, Product, Legal, Compliance, and executive leadership. Key responsibilities include:

• Reviewing and approving information security policies and standards
• Overseeing risk assessment and treatment activities
• Reviewing security incident reports and trends
• Allocating resources for security improvement initiatives
• Ensuring alignment with regulatory requirements and customer expectations

1.2 Shared Responsibility Model

ArcaScience operates under a shared responsibility model that clearly delineates security obligations between ArcaScience as the platform provider and our customers as the data controllers. ArcaScience is responsible for securing the platform infrastructure, application code, data storage systems, and operational processes. Customers retain responsibility for managing their user accounts, configuring access policies within their tenant, classifying their data, and ensuring their use of the platform complies with applicable regulations.

This shared responsibility model is documented in our Master Service Agreement and reinforced through our customer onboarding process, which includes a dedicated security configuration review session.

2. Platform Security Architecture

The ArcaScience platform employs a multi-layered security architecture that protects data and operations at the network, application, and data layers. Each layer implements independent security controls that collectively provide comprehensive protection against a wide range of threat vectors.

2.1 Network Layer Security

Key network security controls include:

• Network segmentation: Production, staging, and development environments are isolated in separate VPCs with no direct routing between them. Within the production environment, web-facing components, application logic, and data stores reside in distinct subnets with security group rules enforcing least-privilege communication paths.
• DDoS protection: Volumetric and application-layer DDoS protection is provided through our CDN partner (AWS CloudFront with AWS Shield Advanced), capable of absorbing attacks exceeding 1 Tbps. Rate limiting and bot detection at the edge prevent application-layer abuse.
• Web Application Firewall (WAF): Custom WAF rules inspect all incoming HTTP/HTTPS traffic for OWASP Top 10 attack patterns, including SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and server-side request forgery (SSRF). Rules are updated weekly based on threat intelligence feeds.
• Private connectivity: For enterprise customers requiring dedicated connectivity, ArcaScience supports AWS PrivateLink endpoints, eliminating the need for data to traverse the public internet.
• DNS security: DNSSEC is enabled on all ArcaScience domains. Internal service discovery uses private DNS zones inaccessible from outside the VPC.

2.2 Application Layer Security

The application layer is built on a containerized microservices architecture deployed on Kubernetes (Amazon EKS), with security controls embedded throughout:

• API security: All API endpoints require authentication via OAuth 2.0 bearer tokens with short-lived access tokens (15-minute expiry) and rotating refresh tokens. API requests are validated against OpenAPI specifications, and malformed requests are rejected before reaching business logic.
• Input validation: All user inputs are validated against strict schemas using server-side validation libraries. Parameterized queries prevent SQL injection, and output encoding prevents XSS. Content Security Policy (CSP) headers restrict script execution to trusted sources.
• Container security: Container images are built from minimal base images (distroless), scanned for vulnerabilities before deployment using Trivy and Snyk, and run with read-only filesystems and non-root users. Pod security policies enforce these constraints at the Kubernetes level.
• Service mesh: Inter-service communication is secured via mutual TLS (mTLS) using an Istio service mesh. Each microservice has a unique cryptographic identity, and all inter-service traffic is encrypted and authenticated.
• Secrets management: Application secrets, API keys, and database credentials are stored in AWS Secrets Manager with automatic rotation. Secrets are never stored in code repositories, configuration files, or environment variables accessible to application code.

2.3 Data Layer Security

Data security controls span storage, processing, and transmission:

• Tenant isolation: Each customer's data is logically isolated using a combination of database-level row security policies and application-level tenant context enforcement. Enterprise customers may opt for physically isolated database instances for additional assurance.
• Data classification: All data elements are classified according to a four-tier sensitivity model (Public, Internal, Confidential, Restricted). Security controls are applied proportionally to classification level, with Restricted data (e.g., patient-level clinical data) receiving the highest level of protection.
• Backup encryption: Database backups are encrypted using separate encryption keys from production data, stored in a different AWS region, and retained according to customer-specified retention policies (default: 90 days).
• Data residency: Customers can select their preferred data residency region (EU-West, US-East, or AP-Southeast). Data never leaves the selected region unless explicitly authorized by the customer for specific operations such as disaster recovery failover.

3. Encryption Standards

Encryption is the cornerstone of data protection in the ArcaScience platform. We employ industry-leading encryption standards for data at rest, data in transit, and cryptographic key management, meeting or exceeding the requirements of all applicable regulatory frameworks.

3.1 Encryption at Rest

All data stored within the ArcaScience platform is encrypted at rest using AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode). AES-256 is approved by the U.S. National Institute of Standards and Technology (NIST) and is the standard required for protecting classified information at the Top Secret level.

Storage System	Encryption Algorithm	Key Length	Key Management
Primary database (PostgreSQL)	AES-256-GCM	256-bit	AWS KMS (CMK per tenant)
Document storage (S3)	AES-256-GCM	256-bit	AWS KMS (SSE-KMS)
Search index (Elasticsearch)	AES-256-GCM	256-bit	AWS KMS
Cache layer (Redis)	AES-256-GCM	256-bit	AWS KMS
Backup storage	AES-256-GCM	256-bit	AWS KMS (separate key)
Log storage	AES-256-GCM	256-bit	AWS KMS

For customers requiring additional control over their encryption keys, ArcaScience supports Bring Your Own Key (BYOK) configurations where customers provide their own AWS KMS Customer Master Keys. In BYOK mode, ArcaScience cannot access customer data without the customer's key being available, providing an additional layer of customer control.

3.2 Encryption in Transit

All data transmitted to and from the ArcaScience platform is protected using TLS 1.3, the most current version of the Transport Layer Security protocol. TLS 1.2 is supported for backward compatibility with legacy clients but is scheduled for deprecation in Q4 2026. TLS 1.0 and 1.1 are not supported.

Our TLS configuration enforces the following cipher suites (in order of preference):

• TLS_AES_256_GCM_SHA384 — AES-256 in GCM mode with SHA-384 for message authentication
• TLS_CHACHA20_POLY1305_SHA256 — ChaCha20-Poly1305 for mobile clients where AES hardware acceleration is unavailable
• TLS_AES_128_GCM_SHA256 — AES-128 in GCM mode (TLS 1.3 only)

Perfect Forward Secrecy (PFS) is enforced for all connections, ensuring that the compromise of long-term keys does not compromise past session keys. Certificate pinning is implemented in our mobile and desktop applications to prevent man-in-the-middle attacks via compromised certificate authorities.

3.3 Key Management

Cryptographic key management follows NIST SP 800-57 recommendations for key lifecycle management:

• Key generation: All encryption keys are generated using cryptographically secure random number generators (CSPRNG) within FIPS 140-2 Level 3 validated hardware security modules (HSMs) provided by AWS CloudHSM.
• Key rotation: Data encryption keys are automatically rotated every 90 days. Customer Master Keys (CMKs) are rotated annually. Key rotation is performed without service interruption and without requiring re-encryption of existing data (envelope encryption model).
• Key storage: Master keys never leave the HSM boundary in plaintext. Data encryption keys are stored encrypted (wrapped) by the master key. The key hierarchy follows an envelope encryption model with three levels: master keys, data encryption keys, and per-object keys.
• Key revocation: Compromised or retired keys can be revoked immediately. Revocation triggers automatic re-encryption of affected data with new keys. Key revocation events are logged and alerted to the security operations team.
• Key escrow: ArcaScience does not escrow customer encryption keys. In BYOK configurations, customers retain sole control of their master keys. Standard configurations use AWS KMS where key material is protected within FIPS 140-2 Level 3 HSMs.

3.4 Application-Level Encryption

Beyond infrastructure-level encryption, certain high-sensitivity data fields receive additional application-level encryption before storage. This includes:

• Patient identifiers and demographic data in clinical datasets
• User authentication credentials (bcrypt with cost factor 12)
• API keys and integration tokens
• Electronic signature data and certificates

Application-level encryption uses per-tenant keys derived from the customer's master key, ensuring that even database administrators with direct access to storage systems cannot read sensitive field values.

4. Identity and Access Management

Identity and Access Management (IAM) is the primary mechanism through which ArcaScience controls who can access the platform, what actions they can perform, and what data they can view. Our IAM implementation is designed to meet the stringent requirements of FDA 21 CFR Part 11, which mandates that electronic records and electronic signatures are trustworthy, reliable, and equivalent to paper records and handwritten signatures.

4.1 Role-Based Access Control (RBAC)

ArcaScience implements a hierarchical RBAC model with five standard roles, each with progressively increasing permissions. Customers can also define custom roles with granular permission assignments.

Role	Description	Key Permissions
Viewer	Read-only access to assigned projects	View dashboards, reports, and BRA outputs
Analyst	Can create and modify analyses within assigned projects	Viewer + create/edit BRA models, import data, run simulations
Reviewer	Can review and approve analyses (segregation of duties)	Analyst + approve/reject analyses, sign-off on reports
Project Admin	Manages project-level settings and team membership	Reviewer + manage project users, configure workflows
Tenant Admin	Full administrative control over the customer's tenant	All permissions + SSO configuration, user management, audit log access

The RBAC system enforces segregation of duties for regulated workflows. For example, the user who creates a benefit-risk analysis cannot be the same user who approves it for regulatory submission. This segregation is enforced at the system level and cannot be overridden, even by Tenant Administrators.

4.2 Multi-Factor Authentication (MFA)

Multi-factor authentication is mandatory for all user accounts. ArcaScience supports the following MFA methods:

• TOTP (Time-based One-Time Password): Compatible with authenticator apps such as Google Authenticator, Microsoft Authenticator, and Authy. Uses HMAC-SHA1 with 6-digit codes and 30-second validity windows.
• WebAuthn/FIDO2: Hardware security key support (YubiKey, Titan, etc.) providing phishing-resistant authentication. This is the recommended MFA method for all users.
• SMS OTP: Available as a fallback method but not recommended for high-security accounts due to the known vulnerabilities of SMS-based authentication (SIM swapping, SS7 attacks). Customers can disable SMS MFA at the tenant level.

MFA enrollment is required during the user's first login. Recovery codes are generated during enrollment and must be stored securely by the user. Account recovery without MFA requires identity verification by the Tenant Administrator and generates an audit log entry.

4.3 Single Sign-On (SSO) and SAML Integration

Enterprise customers can integrate ArcaScience with their existing identity providers using SAML 2.0 or OpenID Connect (OIDC). Supported identity providers include:

• Microsoft Entra ID (formerly Azure Active Directory)
• Okta
• Ping Identity
• OneLogin
• Google Workspace
• Any SAML 2.0 or OIDC-compliant identity provider

When SSO is enabled, ArcaScience acts as a Service Provider (SP), delegating authentication entirely to the customer's Identity Provider (IdP). User provisioning and deprovisioning can be automated via SCIM 2.0, ensuring that employee lifecycle changes in the customer's HR system are reflected in ArcaScience access within minutes.

SSO sessions honor the IdP's session policies. When a user's session expires or is revoked at the IdP, their ArcaScience session is terminated within 60 seconds through backchannel logout notifications.

4.4 Session Management

User sessions are managed with security-hardened parameters designed to minimize the risk of session hijacking or unauthorized access:

• Session timeout: Idle sessions expire after 30 minutes of inactivity (configurable by Tenant Administrators, minimum 15 minutes). Absolute session lifetime is 12 hours, after which re-authentication is required regardless of activity.
• Session binding: Sessions are bound to the user's IP address and User-Agent string. Significant changes in either trigger re-authentication.
• Concurrent session limits: By default, users are limited to 3 concurrent sessions. Tenant Administrators can adjust this limit or restrict to a single session.
• Session tokens: Cryptographically random, 256-bit session tokens are transmitted exclusively over HTTPS in secure, HttpOnly, SameSite cookies. Tokens are rotated after each authentication event and at 15-minute intervals during active use.

5. Audit Trail and Data Integrity

In regulated pharmaceutical environments, the ability to demonstrate that data has not been altered, deleted, or fabricated is not optional—it is a legal requirement. ArcaScience's audit trail system is designed to satisfy FDA 21 CFR Part 11, EU Annex 11, and ICH E6(R2) Good Clinical Practice requirements for data integrity.

5.1 ALCOA+ Compliance

All audit records within the ArcaScience platform conform to the ALCOA+ principles, the gold standard for data integrity in pharmaceutical and clinical environments:

Principle	Definition	ArcaScience Implementation
Attributable	Data is attributed to the person who generated it	Every action is linked to authenticated user identity with timestamp
Legible	Data is readable and permanent	Structured JSON format with human-readable descriptions; immutable storage
Contemporaneous	Data is recorded at the time of activity	Events recorded synchronously with sub-millisecond timestamps (NTP-synchronized)
Original	First recording of data is preserved	Original values preserved in change records; no overwrite capability
Accurate	Data is correct and truthful	Server-side timestamp generation; validated data types; checksum verification
Complete	All data is present	No audit records can be deleted; gap detection alerts on missing sequence numbers
Consistent	Data follows logical sequence	Monotonic sequence numbers; cross-reference validation between related events
Enduring	Data is available throughout retention period	Minimum 15-year retention; geo-redundant storage; format migration guarantees
Available	Data is accessible when needed	Real-time query API; export in CSV, JSON, and PDF formats; sub-second search

5.2 Immutable Audit Logs

Audit logs in the ArcaScience platform are stored in an append-only data store that prevents modification or deletion of existing records, even by system administrators. The immutability of audit logs is guaranteed through multiple mechanisms:

• Append-only storage: Audit logs are written to Amazon S3 with Object Lock enabled in Compliance mode. Once written, log objects cannot be deleted or overwritten until the retention period expires, even by the AWS root account.
• Hash chaining: Each audit record includes a SHA-256 hash of the previous record, creating a blockchain-like chain of integrity. Any tampering with a historical record would break the hash chain, which is verified continuously by an independent monitoring process.
• Independent timestamp authority: Audit record timestamps are countersigned by an RFC 3161-compliant timestamping authority, providing non-repudiable proof of when each record was created.
• Segregation of duties: The systems that generate audit logs are architecturally separated from the systems that store and query them. No single role or credential can both perform a logged action and modify the corresponding log entry.

5.3 Audit Scope

The following categories of events are captured in the audit trail:

• Authentication events: Login success and failure, MFA challenges, SSO assertions, session creation and termination, password changes
• Authorization events: Role assignments, permission changes, access denied events, privilege escalation attempts
• Data events: Record creation, modification, and deletion (including before and after values); data imports and exports; report generation
• Workflow events: BRA model submissions, approvals, rejections, electronic signatures, version promotions
• Configuration events: System setting changes, integration configuration, user management actions
• Security events: Encryption key operations, vulnerability scan results, security alert triggers

5.4 Electronic Signatures

ArcaScience's electronic signature implementation satisfies FDA 21 CFR Part 11 requirements:

• Electronic signatures include the signer's full name, the date and time of signing, and the meaning of the signature (e.g., "Approved," "Reviewed," "Authored")
• Signatures are linked to their respective electronic records such that they cannot be excised, copied, or otherwise transferred to falsify another record
• Signing requires re-authentication (username and password plus MFA) at the time of signature
• Signed records are immediately versioned and locked against further modification

6. Infrastructure Security

ArcaScience's infrastructure is hosted on Amazon Web Services (AWS), leveraging AWS's extensive physical security, network security, and compliance certifications. Our infrastructure architecture is designed for security, availability, and performance across multiple geographic regions.

6.1 Cloud Infrastructure (SOC 2 Certified)

ArcaScience's production infrastructure runs exclusively on AWS, which maintains SOC 1, SOC 2, and SOC 3 certifications, ISO 27001, ISO 27017, ISO 27018, and ISO 27701 certifications, and numerous industry-specific compliance attestations including HIPAA, FedRAMP, and PCI DSS.

Our infrastructure is deployed across multiple Availability Zones (AZs) within each supported region, providing resilience against individual data center failures. Key infrastructure components include:

• Compute: Amazon EKS (Kubernetes) running on EC2 instances in private subnets. Worker nodes use Amazon Linux 2 with CIS Benchmark Level 2 hardening. Node images are rebuilt weekly from a hardened golden AMI.
• Database: Amazon RDS for PostgreSQL with Multi-AZ deployment, automated backups, and point-in-time recovery. Read replicas provide read scaling and can be promoted in the event of primary failure.
• Storage: Amazon S3 with server-side encryption, versioning, and cross-region replication for critical data. S3 bucket policies enforce encryption-in-transit and block public access.
• Networking: AWS VPC with private subnets, NAT gateways for outbound internet access, and VPC endpoints for AWS service access without internet traversal. Network ACLs and security groups implement defense in depth.
• Load balancing: AWS Application Load Balancer (ALB) with AWS WAF integration, TLS termination, and health-check-based routing. Geographic routing directs users to the nearest regional deployment.

6.2 DDoS Protection

Distributed Denial of Service (DDoS) protection is implemented at multiple layers:

• Layer 3/4: AWS Shield Advanced provides always-on network flow monitoring and automatic inline attack mitigation for volumetric, state-exhaustion, and reflection attacks. Shield Advanced includes 24/7 access to the AWS DDoS Response Team (DRT).
• Layer 7: AWS WAF with rate-based rules automatically blocks IP addresses exceeding defined request rate thresholds. Bot detection and CAPTCHA challenges protect against application-layer attacks.
• CDN absorption: CloudFront's globally distributed edge network absorbs attack traffic at points of presence closest to the attack source, preventing it from reaching origin infrastructure.

6.3 Server Hardening

All server instances follow a rigorous hardening standard based on the CIS Benchmarks:

• Unnecessary services, packages, and ports are disabled or removed
• SSH access requires key-based authentication; password authentication is disabled
• All administrative access requires going through a bastion host with session recording
• File integrity monitoring (FIM) detects unauthorized changes to critical system files
• SELinux is enabled in enforcing mode on all Linux instances
• System clocks are synchronized to AWS NTP servers with monitoring for drift

7. Vulnerability Management

ArcaScience maintains a comprehensive vulnerability management program that identifies, prioritizes, and remediates security vulnerabilities across all layers of the technology stack. The program combines automated scanning, manual penetration testing, and community-driven discovery through our responsible disclosure program.

7.1 Penetration Testing

Independent penetration testing is conducted by qualified third-party firms on the following schedule:

• Annual comprehensive assessment: A full-scope penetration test covering network, application, and social engineering vectors is conducted annually by a CREST-accredited firm. The scope includes black-box, grey-box, and white-box testing methodologies.
• Quarterly targeted assessments: Focused penetration tests target specific areas of the platform that have undergone significant changes or that address specific threat scenarios relevant to the pharmaceutical industry (e.g., insider threat, supply chain compromise).
• Pre-release testing: Major platform releases undergo security-focused testing before deployment, including API security testing, authentication bypass attempts, and privilege escalation testing.

Penetration test findings are classified using the CVSS v3.1 scoring system, and remediation timelines are based on severity:

Severity (CVSS)	Remediation SLA	Escalation
Critical (9.0-10.0)	24 hours	Immediate CISO and CEO notification
High (7.0-8.9)	72 hours	CISO notification within 4 hours
Medium (4.0-6.9)	30 days	Included in next sprint planning
Low (0.1-3.9)	90 days	Tracked in vulnerability backlog

7.2 Bug Bounty Program

ArcaScience operates a private bug bounty program through HackerOne, providing a structured channel for independent security researchers to report vulnerabilities. The program offers rewards ranging from $500 for low-severity findings to $15,000 for critical vulnerabilities, with bonus payments for exceptional reports that include proof-of-concept exploits and remediation recommendations.

To date, the bug bounty program has received over 340 submissions, with 47 valid vulnerabilities identified and remediated. The mean time to first response is under 4 hours, and the mean time to remediation for accepted findings is 6.2 days.

7.3 Static and Dynamic Application Security Testing

Automated security testing is integrated throughout the software development lifecycle:

• SAST (Static Application Security Testing): Every code commit triggers static analysis using Semgrep and CodeQL, checking for security anti-patterns, hardcoded secrets, injection vulnerabilities, and unsafe deserialization. Pull requests with high-severity SAST findings cannot be merged.
• DAST (Dynamic Application Security Testing): Automated DAST scans run against the staging environment nightly using OWASP ZAP, testing for runtime vulnerabilities including authentication flaws, session management issues, and injection vulnerabilities in API endpoints.
• SCA (Software Composition Analysis): Dependency scanning identifies known vulnerabilities in third-party libraries and open-source components. Dependabot and Snyk automatically create pull requests for vulnerable dependency updates. Licenses of all dependencies are verified against an approved list.
• IaC scanning: Terraform and Kubernetes manifests are scanned by Checkov and kube-bench for misconfigurations, overly permissive policies, and compliance violations before deployment.

7.4 Patch Management

Operating system and infrastructure patches are applied according to the following schedule:

• Critical security patches: Applied within 24 hours of vendor release, following emergency change management procedures
• High-severity patches: Applied within 7 days, following standard change management procedures
• Routine patches: Applied during monthly maintenance windows, typically the second Saturday of each month
• Application dependencies: Updated within 48 hours for critical vulnerabilities, weekly for non-critical updates

8. Incident Response

Despite comprehensive preventive controls, ArcaScience recognizes that no system is immune to security incidents. Our incident response program ensures rapid detection, containment, eradication, and recovery from security events, with clear communication protocols to keep stakeholders informed.

8.1 Detection

ArcaScience employs multiple detection mechanisms operating continuously:

• Security Information and Event Management (SIEM): Centralized log aggregation and correlation using a cloud-native SIEM solution. Over 400 detection rules monitor for indicators of compromise, anomalous behavior, and policy violations across all platform components.
• Endpoint Detection and Response (EDR): All server instances and developer workstations run EDR agents that provide real-time threat detection, behavioral analysis, and automated response capabilities.
• Network threat detection: VPC Flow Logs, DNS query logs, and WAF logs are analyzed in real-time for indicators of network-based attacks, data exfiltration, and command-and-control communications.
• User behavior analytics (UBA): Machine learning models baseline normal user behavior and alert on anomalies such as unusual login locations, abnormal data access patterns, or suspicious privilege usage.

8.2 Containment

Upon detection of a confirmed security incident, the incident response team executes containment procedures appropriate to the incident type:

• Account compromise: Immediate session termination, credential rotation, and temporary account lockout. Affected user is notified and required to complete identity verification before access is restored.
• Malware detection: Affected systems are isolated from the network. Forensic images are captured before remediation. Lateral movement indicators are investigated across the environment.
• Data exfiltration: Egress traffic is blocked or filtered to prevent further data loss. Affected data is identified through DLP logs and access records. Legal and compliance teams are notified for regulatory impact assessment.
• Service compromise: Affected services are taken offline or isolated. Traffic is rerouted to unaffected instances. Infrastructure is rebuilt from known-good configurations.

8.3 Recovery

Recovery procedures are designed to restore normal operations while preserving forensic evidence:

• Systems are rebuilt from verified clean images rather than cleaned in place
• Credentials and keys that may have been exposed are rotated
• Enhanced monitoring is enabled for a minimum of 30 days post-incident
• Recovery is validated through automated tests and manual verification

8.4 Notification SLAs

ArcaScience commits to the following notification timelines for confirmed security incidents affecting customer data:

Incident Severity	Customer Notification SLA	Regulatory Notification	Update Frequency
Critical (confirmed data breach)	Within 24 hours	Within 72 hours (GDPR)	Every 4 hours until resolved
High (potential data exposure)	Within 48 hours	As required by assessment	Every 8 hours until resolved
Medium (security event, no data impact)	Within 72 hours	Not typically required	Daily until resolved
Low (minor policy violation)	Monthly security report	Not required	Monthly summary

9. Business Continuity and Disaster Recovery

ArcaScience's Business Continuity and Disaster Recovery (BCDR) program ensures that critical platform services can be maintained or rapidly restored in the event of infrastructure failures, natural disasters, or other disruptive events. The program is designed to meet the stringent availability requirements of pharmaceutical organizations that depend on continuous access to benefit-risk data and analyses.

9.1 Recovery Objectives

• Recovery Time Objective (RTO) — 4 hours: In the event of a complete regional failure, full platform functionality will be restored within 4 hours. Partial service (read-only access to existing data and reports) is typically restored within 1 hour through automatic failover to the disaster recovery site.
• Recovery Point Objective (RPO) — 1 hour: Maximum data loss in a disaster scenario is limited to 1 hour of transactions. This is achieved through continuous database replication to the DR site (synchronous within-region, asynchronous cross-region with lag monitoring) and hourly incremental backups of all persistent storage.

9.2 Geographic Redundancy

ArcaScience maintains active-passive disaster recovery configurations for each supported data residency region:

Primary Region	DR Region	Replication Mode	Failover Type
EU-West (Ireland)	EU-Central (Frankfurt)	Async (<30s lag)	Automated with manual approval
US-East (Virginia)	US-West (Oregon)	Async (<30s lag)	Automated with manual approval
AP-Southeast (Singapore)	AP-Northeast (Tokyo)	Async (<60s lag)	Manual (regulatory constraint)

Within each primary region, the platform is deployed across three Availability Zones, providing automatic failover for individual data center failures without service interruption. Cross-region failover is triggered when a regional outage persists beyond 30 minutes or when monitoring detects unrecoverable data corruption.

9.3 Backup Strategy

ArcaScience implements a comprehensive backup strategy with multiple tiers:

• Continuous replication: Database write-ahead logs are continuously shipped to the DR site, enabling point-in-time recovery to any moment within the retention window.
• Hourly incremental backups: All database and storage systems are backed up incrementally every hour. Backup integrity is verified through automated restore testing.
• Daily full backups: Complete system backups are performed daily during low-activity windows. Each backup is verified through automated checksum validation and sample data verification.
• Monthly archive backups: Monthly backup snapshots are retained for the full retention period (default: 7 years for regulated data) in a separate AWS account with independent access controls.

9.4 DR Testing

Disaster recovery capabilities are validated through regular testing:

• Quarterly tabletop exercises: The incident response and operations teams walk through simulated disaster scenarios to validate procedures and identify gaps.
• Semi-annual failover tests: Every six months, a controlled failover to the DR site is executed during a maintenance window. The DR site operates as the primary site for a minimum of 4 hours to validate full operational capability.
• Annual full-scale exercise: An annual exercise simulates a complete regional outage with no advance preparation for the operations team, testing both technical recovery capabilities and organizational response procedures.
• Monthly backup restore tests: Random backup sets are restored to isolated environments and validated for data integrity and completeness.

10. Compliance Framework Mapping

ArcaScience's security program is designed to satisfy the requirements of multiple regulatory frameworks applicable to pharmaceutical companies operating globally. The following table maps our key security controls to the most relevant compliance frameworks.

10.1 FDA 21 CFR Part 11

FDA 21 CFR Part 11 establishes requirements for electronic records and electronic signatures in FDA-regulated industries. ArcaScience's compliance with Part 11 is critical for customers who use the platform to generate and manage records that may be submitted to the FDA.

Part 11 Requirement	ArcaScience Control
System validation (11.10(a))	IQ/OQ/PQ documentation; automated regression testing; change control procedures
Record generation and retention (11.10(b))	Immutable audit trail; 15-year retention; human-readable export
Record protection (11.10(c))	AES-256 encryption; RBAC; backup and recovery procedures
Limited system access (11.10(d))	RBAC with least privilege; MFA; session management controls
Audit trail (11.10(e))	ALCOA+ compliant audit trail; hash-chained immutable logs
Operational system checks (11.10(f))	Input validation; data type enforcement; sequence verification
Authority checks (11.10(g))	Permission verification before every operation; segregation of duties
Device checks (11.10(h))	Session binding; device fingerprinting; anomaly detection
Personnel training (11.10(i))	Role-specific onboarding; annual security training; compliance attestation
Electronic signatures (11.50-11.300)	Unique user ID; re-authentication at signing; signature-record binding

10.2 GDPR

The General Data Protection Regulation (GDPR) applies to the processing of personal data of EU/EEA residents. ArcaScience serves as a Data Processor on behalf of our customers (Data Controllers) and implements the following GDPR-relevant controls:

• Lawful basis: Data Processing Agreements with all customers establish the lawful basis and instructions for processing
• Data minimization: Platform features support pseudonymization and anonymization of personal data; customers can configure data retention policies
• Data subject rights: API and UI tools support data access, rectification, erasure, portability, and restriction of processing requests
• Data protection by design: Privacy impact assessments are conducted for new features; privacy-enhancing technologies are built into the platform
• International transfers: Standard Contractual Clauses (SCCs) are incorporated into all DPAs; EU data residency option ensures data remains within the EU
• Breach notification: 72-hour notification SLA to Data Controllers for confirmed personal data breaches

10.3 ISO 27001

ArcaScience's Information Security Management System (ISMS) is aligned with ISO/IEC 27001:2022 controls. While ArcaScience is pursuing formal ISO 27001 certification (expected Q3 2026), our current control implementation covers all 93 controls in Annex A, organized across the four themes: Organizational, People, Physical, and Technological.

10.4 HIPAA

For U.S. customers who process Protected Health Information (PHI) on the ArcaScience platform, we execute Business Associate Agreements (BAAs) and implement the HIPAA Security Rule's administrative, physical, and technical safeguards:

• Access controls with unique user identification and automatic logoff
• Audit controls for recording and examining system activity
• Integrity controls to protect electronic PHI from improper alteration
• Transmission security with encryption for all PHI in transit
• Workforce training and security awareness programs

10.5 HDS (Hébergeur de Données de Santé)

ArcaScience's EU infrastructure deployment satisfies the requirements of the French HDS certification for hosting health data. Our HDS compliance is inherited from our hosting on AWS's HDS-certified Paris (eu-west-3) region, supplemented by ArcaScience's application-level security controls and data governance procedures.

10.6 Cross-Framework Control Mapping

Control Domain	21 CFR Part 11	GDPR	ISO 27001	HIPAA
Access Control	11.10(d),(g)	Art. 25, 32	A.8.2-A.8.5	164.312(a)
Audit Trail	11.10(e)	Art. 30	A.8.15	164.312(b)
Encryption	11.10(c)	Art. 32	A.8.24	164.312(a)(2)(iv)
Incident Response	—	Art. 33, 34	A.5.24-A.5.28	164.308(a)(6)
Backup/Recovery	11.10(c)	Art. 32	A.8.13-A.8.14	164.308(a)(7)
Risk Assessment	11.10(a)	Art. 35	A.5.1	164.308(a)(1)

11. Appendices: Technical Specifications

Appendix A: Cryptographic Standards Summary

Use Case	Algorithm	Key Length	Standard
Data at rest	AES-256-GCM	256-bit	NIST SP 800-38D
Data in transit	TLS 1.3	256-bit (AES) / 253-bit (X25519)	RFC 8446
Key exchange	X25519 / ECDHE P-256	253-bit / 256-bit	RFC 7748 / NIST SP 800-56A
Digital signatures	Ed25519 / ECDSA P-256	256-bit	RFC 8032 / FIPS 186-4
Password hashing	bcrypt	Cost factor 12	OWASP recommendation
Audit log integrity	SHA-256	256-bit	FIPS 180-4
Random number generation	CSPRNG (DRBG)	256-bit seed	NIST SP 800-90A

Appendix B: Network Architecture Summary

Component	Technology	Security Controls
Edge / CDN	AWS CloudFront	TLS 1.3, WAF, DDoS protection, geo-restriction
Load Balancer	AWS ALB	TLS termination, health checks, request routing
Application Tier	Amazon EKS (Kubernetes)	Pod security, mTLS (Istio), network policies
Database Tier	Amazon RDS PostgreSQL	AES-256, Multi-AZ, private subnet, IAM auth
Object Storage	Amazon S3	SSE-KMS, Object Lock, versioning, access logging
Secrets	AWS Secrets Manager	Auto-rotation, IAM policies, audit logging
DNS	Amazon Route 53	DNSSEC, private hosted zones, health checks

Appendix C: Security Monitoring and Alerting

Monitoring Category	Tools	Alert Threshold	Response SLA
Failed authentication	SIEM, application logs	5 failures in 10 minutes	Auto-lockout + review within 1 hour
Privilege escalation	SIEM, UBA	Any unauthorized attempt	Immediate investigation
Data exfiltration	DLP, network monitoring	Anomalous data volume or pattern	15-minute investigation SLA
Infrastructure anomaly	CloudTrail, GuardDuty	ML-based anomaly detection	30-minute investigation SLA
Certificate expiry	Certificate monitoring	30 days before expiry	Renewal within 7 days
Vulnerability detection	Trivy, Snyk, OWASP ZAP	Critical/High severity	Per remediation SLA table

Appendix D: Compliance Certifications and Attestations

Certification / Attestation	Status	Scope	Validity
SOC 2 Type II	Active	Security, Availability, Confidentiality	Jan 2025 — Dec 2025 (renewal in progress)
ISO 27001:2022	In Progress	Full ISMS	Expected Q3 2026
HIPAA BAA	Available	PHI processing on platform	Per customer agreement
FDA 21 CFR Part 11	Compliant	Electronic records and signatures	Continuous (self-assessed + audited)
GDPR DPA	Available	Personal data processing	Per customer agreement
HDS	Compliant	Health data hosting (France/EU)	Via AWS HDS-certified infrastructure

Appendix E: Contact Information