Trust & Security.

Sentinel operates as a data processor under GDPR (EU 2016/679). Investment funds using Sentinel remain the data controllers — Sentinel provides the secure technology layer for their compliance operations.

• ·Data Processing Agreements (DPA) available for all clients, defining scope, purpose, and safeguards for personal data processing
• ·Data minimisation principle applied throughout: we only collect and process data strictly necessary for KYC/AML onboarding and document signing workflows
• ·Right to erasure and portability supported — fund clients can request full data export or deletion at any time

• ·In transit: All connections secured with TLS 1.3. No unencrypted traffic is accepted at any endpoint. HSTS enforced across all domains
• ·At rest: All databases use AES-256 encryption at rest. File storage uses server-side encryption with managed keys (SSE). Backup volumes are encrypted with the same standard
• ·Sensitive fields: Cryptographic secrets, API keys, and signing material are stored in environment-level vaults, never in application databases

• ·All primary data (database, file storage, application hosting) is processed and stored within the European Union
• ·No personal data is transferred outside the EU/EEA without explicit client authorisation and appropriate safeguards (Standard Contractual Clauses where applicable)
• ·Subprocessors are contractually bound to maintain equivalent data protection standards

• ·Signed documents and forensic evidence bundles are stored in write-once, read-many (WORM) compliant object storage with retention policies that prevent modification or deletion during the retention period
• ·Every document version is preserved with full audit trail. Any modification is cryptographically detectable
• ·File integrity is verified on every access using cryptographic checksums

• ·All document operations (upload, review, signature, status change) generate immutable audit log entries with timestamp, user identity, IP address, and action detail
• ·Audit logs are append-only — they cannot be modified or deleted by any user, including system administrators
• ·Full version history is maintained for every document, enabling complete reconstruction of the document lifecycle

• ·Documents with regulatory expiry dates (e.g. proof of address, ID documents) are tracked automatically with configurable expiry alerts
• ·Retention policies are configurable per fund to match jurisdiction-specific requirements (e.g. 5AMLD record-keeping obligations)

Sentinel implements a multi-layer electronic signature system designed to provide strong legal validity and forensic robustness without relying on third-party signature vendors. The system meets the requirements for an Advanced Electronic Signature (AdES) under the EU eIDAS Regulation (EU 910/2014) and is fully compliant with the US ESIGN Act and UETA.

Every signing event produces a cryptographic hash chain that links each step of the signing process:

1. 1.Investor signature → produces hash H₁ covering all form data, signature image, signer identity, and timestamp
2. 2.Compliance counter-signature → produces hash H₂ that includes H₁, creating a verifiable chain
3. 3.Director final signature → produces hash H₃ that includes H₂, completing the chain

Each hash uses HMAC-SHA256 with a server-side secret key, ensuring that even with database access, hashes cannot be recomputed without the signing key. Any modification to any step in the chain invalidates all subsequent hashes.

Every signature is independently timestamped by an external Time Stamp Authority (TSA) compliant with RFC 3161:

• ·Timestamp requests are sent to accredited TSA providers immediately after each signature
• ·The TSA token cryptographically binds the document hash to a specific point in time, certified by a trusted third party
• ·TSA tokens are stored alongside the signature and are independently verifiable — the timestamp proof does not depend on Sentinel's infrastructure
• ·Multiple TSA providers are configured with automatic fallback for high availability

The final signed PDF contains an embedded digital signature conforming to the PAdES standard (ETSI EN 319 142):

• ·Signature format: ETSI.CAdES.detached — the European standard for advanced electronic signatures in PDF
• ·Each signer receives an X.509 certificate issued by Sentinel's Certificate Authority, binding their identity (name, email, role) to the signature
• ·The signed PDF is self-verifiable — any standard PDF reader (Adobe Acrobat, Foxit, Preview, etc.) can independently validate the digital signature without contacting Sentinel
• ·Certificate chain is embedded in the document for offline verification
• ·Combined with RFC 3161 timestamps, the system achieves PAdES-T level assurance (signature + trusted timestamp)

Before any signature is processed, the system enforces:

1. 1.Explicit legal consent: The signer must read and accept a legal declaration referencing the applicable regulatory framework (ESIGN Act for US operations, eIDAS for EU operations). Consent is recorded with full text, timestamp, and explicit acceptance — forming part of the immutable forensic evidence
2. 2.Email-based One-Time Password (OTP): A 6-digit verification code is sent to the signer's registered email address. This provides proof of account possession beyond the active session, equivalent to a second authentication factor at the moment of signing

Every signature produces a comprehensive forensic evidence record stored immutably:

• ·Signer identity (name, email, user ID, role)
• ·Signature data (typed text or drawn image)
• ·Full form data snapshot at the moment of signing
• ·Consent record (legal text accepted, timestamp, explicit acceptance flag)
• ·Cryptographic hashes of all the above
• ·IP address and user agent
• ·RFC 3161 TSA token
• ·Hash chain position and all previous chain hashes

This evidence bundle is designed to withstand legal challenge by providing a complete, cryptographically verifiable record of the signing ceremony.

• ·On-demand integrity verification: Any signed document can be verified at any time through a dedicated verification endpoint that recomputes the entire hash chain and confirms nothing has been altered
• ·Public verification: Each signed document includes a QR code linking to a public verification page (no authentication required) where any party can independently confirm document authenticity
• ·TSA verification: Timestamp tokens are cryptographically verified against the document hash, confirming both the timestamp's authenticity and the document's integrity at the certified time

• ·Signing endpoints enforce rate limiting to prevent abuse (maximum attempts per user within configurable time windows)
• ·OTP requests and verification attempts are independently rate-limited
• ·Anomaly detection monitors signing patterns and flags suspicious activity (e.g. a single source signing documents across multiple unrelated accounts)

• ·Granular role system: Investor, Operations, Chief Compliance Officer, Director, with distinct permission sets
• ·Per-user permission overrides allow fine-grained access control beyond role defaults
• ·All role assignments and permission changes are logged in the immutable audit trail

• ·Session-based authentication with secure, HTTP-only, same-site cookies
• ·Support for Single Sign-On (SSO) via industry-standard protocols (OIDC/OAuth 2.0)
• ·Password policies enforce minimum complexity requirements
• ·Account lockout after repeated failed authentication attempts

• ·Sessions are bound to the authenticated user and cannot be transferred
• ·Automatic session expiry after configurable periods of inactivity
• ·Concurrent session management with visibility into active sessions

• ·Every user action that modifies data generates an immutable audit log entry
• ·Logs capture: user identity, action type, target resource, timestamp, IP address, and before/after state where applicable
• ·Audit logs are preserved independently and cannot be modified by any user role, including administrators
• ·Logs are searchable and exportable for regulatory reporting

• ·Application and data infrastructure hosted within the European Union
• ·Global edge network for content delivery and low-latency access worldwide
• ·DDoS protection and Web Application Firewall (WAF) active on all endpoints, filtering malicious traffic before it reaches the application layer

• ·Managed relational database with automated daily backups and point-in-time recovery capability
• ·All data encrypted at rest (AES-256) and in transit (TLS 1.3)
• ·Connection pooling and automatic scaling to handle variable workloads
• ·Database credentials are rotated regularly and never stored in application code

• ·Object storage with 11-nines (99.999999999%) durability for all uploaded documents
• ·Server-side encryption (AES-256) applied automatically to all stored objects
• ·Access controlled via short-lived, scoped credentials — no permanent keys in the application layer
• ·Geographically distributed storage for redundancy and disaster recovery

• ·Real-time monitoring of application health, error rates, and performance metrics
• ·Automated alerting for anomalies, errors, and security-relevant events
• ·Defined incident response procedures with escalation paths
• ·Regular security reviews and dependency vulnerability scanning as part of the development lifecycle