Security Overview / Security Whitepaper

Last updated: 25 October 2026 (version 1.0).

Review cadence: annual, and on any material change of the platform architecture

1. Introduction

PassportScan Cloud is a Software-as-a-Service platform operated by GlobeID Limited ("GlobeID") that lets accommodation providers capture guest identity documents, obtain consent and signatures, and fulfil statutory guest-registration obligations (police, statistics and border authorities) and PMS integration.

This document describes the security architecture and the technical and organisational measures that protect the platform and the personal data processed on it. It is intended for customers, prospects and auditors, complements the Data Processing Agreement (DPA) and the Sub-processor List, and is the reference answer to security questionnaires. It describes the production platform as deployed at the effective date of this document.

2. Security programme and compliance

• GlobeID operates an Information Security Management System (ISMS) aligned with ISO/IEC 27001:2022, with a named Chief Information Security Officer, a risk register and a Statement of Applicability; the ISMS is reviewed through internal audits and management reviews planned on an annual cycle.
• GDPR: GlobeID acts as processor for guest data under the DPA and has appointed an external Data Protection Officer. Records of processing, a DPIA for guest identity data and a data-subject-rights procedure are maintained.
• Payment card data is handled exclusively by Stripe; PassportScan does not operate a Cardholder Data Environment and never receives card numbers, CVV or expiry dates.
• Control monitoring is continuous through a compliance automation platform connected to the cloud, source-code and identity providers; independent penetration tests are commissioned periodically and findings are tracked to closure.

3. Hosting and architecture

4. Network security

• Private by default: every service runs in private subnets of a dedicated VPC. Only the customer-facing front-ends, the staff administration console and two public APIs are reachable from the Internet, through Amazon API Gateway and a public Application Load Balancer. The admin console is protected by AWS WAF and its own authentication with personally assigned staff accounts and enforced multi-factor authentication. All internal microservices, the automation engine and the OCR engine are reachable only from inside the VPC or through the company VPN.
• Web application firewall: the public edge (API Gateway stages and the public load balancer) is protected by AWS WAF. The AWS managed Amazon IP Reputation List and Known Bad Inputs rule groups block malicious sources and payloads, the AWS Core Rule Set (OWASP-aligned) is evaluated on every request, and rate limiting blocks abusive sources, with stricter limits on authentication endpoints.
• Transport encryption: public endpoints accept TLS 1.2 and TLS 1.3 only (API Gateway security policy TLS_1_2; load balancer policy ELBSecurityPolicy-TLS13-1-2-2021-06 with modern ECDHE-GCM cipher suites). HTTP is redirected to HTTPS and HTTP Strict Transport Security (HSTS) is enforced on the public load balancer. Certificates are issued and renewed automatically by AWS Certificate Manager.
• Administrative access: engineers reach internal services only through a zero-trust VPN tied to their individual identity; there is no SSH or RDP exposed to the Internet, and no bastion host.
• Network logging: VPC Flow Logs (all traffic) and S3 server-access logs are retained for 90 days.

5. Data security

5.1 Encryption

5.2 Data location and residency

• Core platform services and the primary databases are hosted exclusively in AWS eu-west-1 (Ireland); no cross-region replication of databases is configured.
• Where a customer enables document-image storage, images are stored in the S3 region aligned with the property's jurisdiction. Provisioned regions: eu-west-1 (Europe), us-east-1 (North America), sa-east-1 (South America), ap-southeast-1 (Asia-Pacific) and ap-southeast-2 (Australia). Each regional bucket applies the same encryption, versioning and access-logging configuration.
• Transfers outside the EEA are covered by the AWS Data Processing Addendum and Standard Contractual Clauses, as described in the DPA.

5.3 Secrets and keys

• Application secrets, API keys and encryption keys are stored in AWS Systems Manager Parameter Store (SecureString) and injected into containers at start-up; they are never committed to source code or baked into images.
• Database credentials are either generated and rotated by AWS (RDS-managed secrets in AWS Secrets Manager) or stored as SecureStrings in AWS Systems Manager Parameter Store and injected into containers as secrets at start-up.
• Secret changes in production are performed through an audited operations workflow, not by hand on the console. Application database passwords are rotated on a schedule by our internal operations platform, with zero downtime.

5.4 Backups and retention

• Aurora MySQL: automated daily backups with 15-day retention and continuous point-in-time recovery; deletion protection enabled; a final snapshot is taken before any cluster deletion.
• Object storage: versioning with 90-day retention of previous versions, protecting against accidental deletion or overwrite.
• At the end of the contract, customer data is returned to the customer and/or deleted at its request, within 30 days of the request, as set out in the DPA; backup copies then expire through the retention cycle above.

6. Identity and access management

• Customer users authenticate through the platform's identity provider (Clerk) with email verification, session management and optional multi-factor authentication; access within a customer account is role-based.
• GlobeID staff: access to source code, CI/CD and the internal management console is through the GitHub organisation with enforced two-factor authentication. No engineer holds standing access to the production AWS account, and no credential held by a person can assume a role in it: production is changed and operated exclusively through our internal operations platform and audited operations workflows, with no console or command-line path for engineers. Developers have least-privilege access to the development and staging accounts only. Monitoring and operations use dedicated least-privilege roles; the limited operational actions available to our operations platform (for example rolling restart, maintenance mode, scheduled credential rotation, approved one-off data tasks and database snapshots) are scoped to named resources, gated by role and, for production data operations, by a second administrator, and audited. A documented emergency (break-glass) procedure is restricted to designated organisation owners, runs only through our CI/CD system and is recorded and reviewed every time it is used.
• Production database access is not granted permanently to engineers: it is requested just-in-time through our internal operations platform with a stated reason, approved by a second administrator (never the requester), provisioned as a database user scoped to one database and one access level, never with schema-change rights, time-limited (in production at most 4 hours for read access and 1 hour for write access) and automatically removed at expiry; credentials are shown only to the requester. Every request, approval and revocation is recorded. Exporting production data to workstations is prohibited.
• Production data stays in production: development and staging use synthetic or anonymised data only. Database snapshots are restored only into a new database in the environment they were taken from, so production data is never restored into development or test environments; a production restore requires a stated reason and the approval of a second administrator. Corrections to production data are made only through pre-declared, code-reviewed tasks, tested first in staging and approved by a second administrator — never through ad-hoc SQL.
• Operator activity audit trail: all privileged operations performed through the operations platform, including access to production log content — access requests and approvals, release promotions and rollbacks, environment power state changes, configuration changes, document approvals and electronic signatures — are logged with the identity of the operator (GitHub SSO, 2FA enforced), timestamp and outcome, and are available as evidence to auditors.
• CI/CD to AWS authenticates through GitHub OpenID Connect federation with a dedicated deployment role per environment, restricted to the named repositories of the platform.
• Joiner/mover/leaver procedures, screening and confidentiality undertakings are part of the HR security procedure; access reviews are performed periodically.

7. Secure development and change management

• Every change reaches production through Git: pull request, independent code review (approval by someone other than the author), automated checks and a branch-per-environment promotion flow (development → staging → production). Each promotion to staging and to production is requested by one administrator and approved by a different administrator through the operations platform, with an explicit acknowledgement of any database migrations it carries; promotion to production also requires a QA sign-off on the staging release. Each change set is traceable from the ticket to the deployed version, and production deployments outside the operations platform are refused except under the break-glass procedure.
• Container images are built once and scanned for known vulnerabilities on push to the registry; production registry tags are immutable (a released tag can never be silently replaced) and production pulls the exact image digest validated in staging — nothing is rebuilt for production.
• Infrastructure changes follow the same path (Terraform plan on pull request, apply on merge), giving a complete, reviewable audit trail of production changes.
• Releases can be rolled back per component; the deployed version of every component is recorded before each promotion.

8. Logging, monitoring and incident response

• Centralised logs: application and access logs from every service are shipped to Datadog (EU site, datadoghq.eu) and Amazon CloudWatch; application logs are retained for up to 90 days. Personal data and secrets are masked in the services before logs are sent to Datadog, and again when displayed: through our operations platform, staff other than administrators see production log content with personal values masked in place, and automated and AI tools receive no request or response payloads, while the information needed for diagnosis (error messages, request identifiers, status codes) remains visible. Every access to production log content is audited.
• Cloud audit and threat detection: AWS CloudTrail records every management API call made in the production account, across all regions, with log file integrity validation and versioned storage; Amazon GuardDuty continuously analyses CloudTrail, VPC Flow Logs and DNS activity in every region we operate in for threats such as credential misuse, reconnaissance and communication with known-malicious hosts; findings are reviewed by the operations team.
• Alerting: CloudWatch alarms on databases, caches, load balancers, API Gateway and ECS task lifecycle events notify the operations team through SNS; application performance is monitored in Datadog; infrastructure health, queues, costs and deprecation notices per environment are consolidated in the operations platform's monitoring console.
• Public status page: platform availability is monitored externally and published at https://status.passportscan.net, with automatic incident and maintenance communication.
• Incident response: a documented Incident Response & Data Breach Procedure defines severity levels, roles and escalation. Personal-data breaches are notified to affected customers without undue delay and in any case within 48 hours, as set out in the DPA, and to the supervisory authority within 72 hours where required (GDPR Art. 33).
• Vulnerability disclosure: security researchers can report issues under the Vulnerability Disclosure Policy (security@passportscan.net).

9. Business continuity and disaster recovery

• Production runs on managed AWS services across three availability zones in eu-west-1: Aurora storage is replicated six ways across the three zones, core services run at least two tasks spread across zones with automatic scaling on load, and ECS automatically replaces a failed task in a healthy zone behind the load balancers. Deployments use a circuit breaker that rolls back automatically when a new version fails its health checks.
• Databases can be restored to any point in time within the 15-day retention window; the restore procedure is part of the annual disaster-recovery exercise.
• A Business Impact Analysis and a Business Continuity & Disaster Recovery Plan define recovery objectives for the platform (recovery time objective under two hours for the core check-in service; recovery point objective in the order of minutes thanks to point-in-time recovery).
• Third-party dependencies (cloud provider, identity provider, payment provider, log management, bot protection and business communication services) are assessed in the supplier security process and listed in the Sub-processor List.

10. Sub-processors

Third parties that process customer personal data on GlobeID's behalf are listed, with their purpose and processing location, in the public Sub-processor List at https://www.passportscan.net/sub-processor/. Customers are notified of additions in accordance with the DPA.

11. Shared responsibility

GlobeID is responsible for the security of the platform as described above. Customers remain responsible for: managing their users and credentials (including enabling MFA), securing the devices and networks used to access the platform, configuring retention and regional storage options lawfully, providing privacy notices to guests, and the security of any PMS or third-party system they connect.

12. Contact

Security questions and questionnaires: security@passportscan.net Privacy and DPO: privacy@passportscan.net GlobeID Limited, The Black Church, St. Mary's Place, Dublin 7, D07 P4AX, Ireland (CRO 559612)