This help document details all Venue Directory system information in relation to Infrastructure, Security and Application Management.

TABLE OF CONTENTS

• Cyber Essentials certified
• Site Hosting and data residency
• Infrastructure
• Security controls
• Identity and access management
• Mail delivery
• Internal Office Systems
• Disaster Recovery and backups
• Monitoring, logging and alerting
• Application upgrades and SDLC
• Environment strategy and segregation
• Endpoint protection and firewalls
• Supported browsers and mobile compatibility
• Application diagram
• Frequently Asked Questions

Cyber Essentials Plus certified

• Cyber Essentials is a UK Government IT assurance scheme operated by the National Cyber Security Centre. It encourages organisations to follow good security practices to protect them from external and internal network threats.
• Venue Directory achieved Cyber Essentials certification on 5 March 2021 and has renewed it annually since then. 
•  In April 2025, Venue Directory achieved Cyber Essentials Plus (CE+), which includes hands‑on technical verification. Certification Number: a339a175-89e7-4663-a5a7-e42b6d57746e. You can validate the accreditation via the QR code provided with the certificate.

• As part of CE+, we operate daily vulnerability monitoring across endpoints and infrastructure. Critical and important vulnerabilities are remediated within 14 days of patch availability.

Site Hosting and data residency

• All public websites and applications operated by Venue Directory are hosted in Microsoft Azure and Amazon Web Services (AWS). 
• Primary regions: 
  • Azure: North Europe (Dublin) 
  • AWS: eu-west-1 (Dublin)
• Services are deployed on virtual machines and managed cloud services. Data residency remains within the European Economic Area (EEA).
• Infrastructure is designed to scale on demand. New instances can be provisioned in minutes via templates and automation.
• Azure and AWS maintain broad compliance coverage (e.g., ISO 27001, SOC 1/2). These provider certifications support our controls but do not by themselves establish compliance for our applications.

Infrastructure

Server infrastructure

• Web/application servers run on Azure VMs.
• Database servers and the mail relay run on AWS EC2. 
• Typical VM sizes range from 2 vCPU / 8 GB RAM (internal workloads) to 8 vCPU / 112 GB RAM (production database).
• Operating systems:
  • Windows Server 2019/2022 (x64)
  • Ubuntu 22.04 LTS (Linux)
• Web servers:
  • Windows: IIS 10
  • Linux: Apache and Nginx
• Transport security: TLS 1.3 (TLS 1.2 remains enabled for backward compatibility where required). Public endpoints use valid certificates and disable legacy protocols/ciphers.
• Disk encryption: All OS and data disks are encrypted (Windows: BitLocker; Linux: dm-crypt/LUKS).
• Administrative access: Restricted to authorized staff using IP allowlists/VPN and MFA. No public management ports are exposed.
• Endpoint protection and health: All servers run CrowdStrike EDR and Microsoft monitoring tools. Regular vulnerability assessments verify patching and control effectiveness.

Database infrastructure

• Primary relational database: Microsoft SQL Server 2022 Enterprise on AWS EC2.
• Additional RDBMS: MySQL and PostgreSQL (Linux) for internal/CMS workloads.
• Multi-tenant isolation: Customer solutions segregate each client’s data into dedicated databases with distinct credentials to minimize cross-tenant risk.
• Non-relational services: Redis (distributed cache), Azure Blob Storage, and Azure Table Storage.
• Backup and restore: 
  • Transaction log backups every 15 minutes enable point-in-time restore (RPO: 15 minutes).
  • Daily encrypted backups are shipped to separate storage.
  • Backups are protected by encryption and access controls.

Development team environment

• Managed Windows 10/11 Pro laptops/desktops (Intel i7/i9, 16–32 GB RAM, 512 GB+ SSD) with BitLocker and CrowdStrike.
• Identity: Microsoft Entra and Okta SSO.
• Tooling: Visual Studio 2022 / Rider, SQL Server Management Studio, Redis Desktop Manager, Azure Storage Explorer, Remote Desktop Manager.
• Code and CI/CD: Azure DevOps (GitHub), with secure HTTPS/SSH access.

Security controls 

• Transport security: Public services use modern cipher suites with TLS 1.3 preferred and RSA 2048-bit/ECDSA certificates.
• Patching: Servers and applications are regularly patched; vulnerability scans track compliance with remediation SLAs.
• Input security: Applications use parameterized queries and validation to mitigate SQL injection and other OWASP Top 10 risks.
• Secrets and keys: Encryption keys for Azure disks are stored in Azure Key Vault. Access is controlled through role-based access and audited.
• Network security: Inbound access to services is minimized and restricted via load balancers, security groups/NSGs, and firewall rules.

Identity and access management 

• Authentication: 
  • All user logins require an email address and password.
  • Multi-factor authentication (MFA) using a one-time passcode (OTP, 10-minute expiry) is required when the user’s session has expired in that browser or when signing in from a new browser/device.
• Password policy: 
  • Minimum length: 12 characters.
  • Composition: mix of uppercase and lowercase letters, numbers, and symbols.
  • Password storage: Passwords are one‑way hashed using a secure algorithm; plaintext passwords are never stored. Password reset requires access to the registered email address, and the user must set a new password upon next login.
  • Administrative accounts: Access is limited to authorized personnel and protected by MFA, IP/VPN restrictions, and least privilege.

Mail delivery

• Outbound application email (e.g., enquiries, documents, claims, contact forms) is delivered via a Postfix MTA on Ubuntu running in AWS.
• Security:
  • Enforced TLS for server-to-server delivery where the recipient supports it.
  • DKIM signing on all messages (current key length: 1024 bits).
  • SPF is used to authorize Venue Directory’s sending hosts.
• SPF guidance for GRATIS agents: 
  • Add the following mechanism to authorize venuedirectory.com to send on your behalf:

  • include:venuedirectory.com

  • Ensure your domain’s SPF record remains within the 10‑DNS‑lookup limit and ends with an appropriate qualifier (e.g., -all).
• Note: Deliverability metrics fluctuate; we monitor reputation, bounces, and blocklists and adjust as needed.
  
  

Internal Office Systems

• Productivity: Microsoft 365; document storage in Box; email via Outlook; all protected by Okta SSO.
• Device security: Full-disk encryption, least-privilege user accounts (no local admin for standard users), Windows Firewall, and Netskope for secure access scanning.
• Passwords for corporate systems follow Venue Directory’s strong password standard and recovery is restricted to authorized administrators.

Disaster recovery and backups

• In the event of a major incident affecting the primary region, Venue Directory can rebuild infrastructure and restore services in an alternate region using our GitHub repositories and automated deployment pipelines.
• Source control
  • Application and infrastructure code is stored in GitHub (Git). Branch protection, reviews, and CI/CD ensure reproducible builds and deployments.
• Database backups
  • Microsoft SQL Server databases are backed up on a continuous schedule (including frequent log backups) to enable point‑in‑time recovery.
  • Backups are stored in Amazon S3 buckets located in a different AWS region than production to ensure recoverability if the primary region is unavailable.
  • Backups are encrypted at rest (SSE‑KMS) and protected by IAM policies; integrity checks and retention policies are enforced.
• Recovery process
  • If the primary region is impacted, new infrastructure is provisioned in the alternate region, application artifacts are deployed from GitHub, and databases are restored from S3 backups.
  • DNS and traffic routing are updated to direct users to the recovered environment once validation checks pass. 
• Operational validation
  • Backup jobs and restores are monitored and alerted; periodic restore tests validate recovery procedures and Recovery Point/Time Objectives.

Monitoring, logging, and alerting

• Platform monitoring: Azure Monitor and Log Analytics provide health checks, metrics, and log analytics for Azure services.
• Security posture: Microsoft Defender for Cloud (formerly Azure Security Center) monitors configurations, threats, and recommendations across cloud resources.
• Performance and APM: Azure Application Insights for web/application telemetry; Datadog for cross-platform performance logs, dashboards, and alerting.
• Alerting: Notifications are sent to Slack channels and email distribution lists monitored by the team.
• Availability: Our recent 3‑month average SLA availability is 99.93%.

Application upgrades and SDLC

• Delivery model: Trunk-based development with prioritized backlog and continuous integration.
• Review and testing: Development in pre-production; QA feedback cycles.
• Security scanning with Mend and Checkmarx before promotion to UAT/production. UAT for regression and quality assurance; training and client communications prepared.
• Release: Iterations are released to production with monitoring and the ability to roll back if required.

Environment strategy and segregation

Our environment strategy follows a clearly segregated, least‑privilege model across four tiers: Development, Staging, User Acceptance Testing and Production. Production tier is isolated at the network from non-production environments, identity, data, and deployment levels to reduce risk and ensure changes are validated progressively before reaching customers.

Scope and purpose

• Dev: Rapid iteration by engineers; feature development and integration with non‑production dependencies; uses representative but synthetic/anonymized data.
• Staging: Automated and manual QA validation; security and performance checks on build artifacts intended for UAT; uses seeded test data, strictly non‑customer.
• UAT: Business stakeholder and limited client validation; release‑candidate builds only; mirrors production configuration closely with anonymized or subsetted datasets as appropriate.
• Production: Customer‑facing workloads; hardened configuration, restricted change windows, and continuous monitoring.

Segregation controls

• Network isolation: Production environment resides in separate VNet/VPC with distinct subnets and routing; no peering that permits traffic between non‑prod and prod. Inbound access is restricted through load balancers, security groups/NSGs, and firewall rules. Break‑glass pathways are disabled by default and time‑bound when enabled.
• Identity and access: Role‑based access control (RBAC) separates duties. Non‑production access is wider for build/test roles; production access is limited to a smaller, authorized on‑call and release group with MFA and IP/VPN restrictions. Service principals/managed identities are scoped per environment and follow least privilege.
• Secrets and configuration: Environment‑specific secrets are stored in separate Key Vaults/secret managers per environment. No sharing of credentials across environments; production secrets are never present in non‑prod.
• CI/CD promotion gates: Dev → Test: unit/integration tests and static analysis must pass. Test → UAT: QA sign‑off, vulnerability thresholds met, and performance baselines within agreed limits. UAT → Prod: UAT acceptance, change record approval, security checks (including dependency and image scans), and a deployment plan with rollback steps.
• Change control and deployment: Non‑prod deployments are on demand based on PR approvals. Production changes follow documented change control with scheduled windows or progressive rollout (e.g., blue‑green or canary where applicable). All deployments are automated via pipelines; no ad‑hoc manual changes on servers.
• Monitoring and logging: Telemetry is enabled in all environments with environment tagging. Alert thresholds and escalation are strictest in Prod.
• Security baselines: Common hardening (TLS 1.3 preferred, patched OS, EDR) applies in all environments, with the most restrictive settings in Prod. Administrative interfaces are never exposed publicly; access requires VPN/Netskope and MFA.

Environment‑specific notes

• Dev: Frequent updates; feature flags isolate work in progress. Access limited to engineering. Non‑prod mail/DNS endpoints prevent unintended external notifications.
• Staging: Mirrors integration points (e.g., Redis, storage, mail relay) with non‑prod instances. Used for automated regression and DAST against non‑prod URLs.
• UAT: High‑fidelity configuration to Prod, including VM sizes and scaling parameters where feasible. External integrations use sandbox credentials. Stakeholder testing occurs here; defects route back to Dev/Staging.
• Production: High availability where required, immutable artifacts from the same pipeline that produced the UAT build. Backups, monitoring, and incident response hooks are enabled. Post‑deployment validation and automated rollbacks are in place.

Release and rollback strategy

• Releases advance the same signed artifact through Dev → Staging → UAT → Prod without rebuilds, ensuring provenance and reproducibility.
• Rollback uses versioned artifacts and database restore/feature flag disablement as appropriate. Database changes follow backward‑compatible patterns and are verified in UAT prior to Prod.

Third‑party and external integrations

• Each environment uses distinct credentials, endpoints, and API keys for external services (e.g., payments, mail, storage). Production keys are restricted to production pipelines and vaults only.

Endpoint protection and firewalls

• Servers use CrowdStrike EDR; Microsoft security agents are kept up to date.
• Network access:
  • Inbound traffic is restricted to required ports via load balancers and network security groups (NSGs/security groups).
  • Source restrictions are applied where possible (office IP ranges, VPNs and Netskope). Temporary access is time-bound. 
  • Host firewalls (Windows Firewall/iptables) provide defense in depth.
    
    

Supported browsers

• We support current and recent major versions of Microsoft Edge, Mozilla Firefox, Google Chrome, and Apple Safari.
• Browsers released prior to 2018 are not supported. Internet Explorer 11 is end-of-support (Microsoft EOL: 15 June 2022) and not supported.

Mobile compatibility

• New applications are developed with responsive design to adapt to device screen sizes.
• We continue to improve legacy applications to ensure a consistent user experience on mobile and tablets.

Application diagram

• An up-to-date application and network diagram is maintained internally and is available upon request to authorized stakeholders.

Frequently Asked Questions

• Disk encryption: We use Azure Disk Encryption (BitLocker on Windows, dm-crypt on Linux). Encryption keys are stored in Azure Key Vault.
• Intrusion protection monitoring: Microsoft Defender for Cloud monitors resources and alerts on malicious activity and misconfigurations; CrowdStrike provides endpoint detection and response.
• Email delivery (technical): Application services connect securely to a Postfix mail relay (Ubuntu on AWS) over a restricted network path. Messages are transmitted using TLS where supported, signed with DKIM, and authorized via SPF. OTP/MFA and other notifications follow the same mail path.