Legal documents
Draft — this document is still being finalised. Details marked “to be confirmed” are not yet final.

Internal Policy — Build Your Vision Ltd (BYV People Hub)

Information Security Policy

  • Last updated 30 October 2026
  • Website: byvpeoplehub.com
  • Policy owner: [name or role · to be confirmed]
  • Next review: [date · to be confirmed]
Contents · 20 sections

1.Purpose and Scope

This policy sets out the technical and organisational measures Build Your Vision Ltd ("the Company") applies to protect the confidentiality, integrity, and availability of information it holds — including Employee Data processed on behalf of People Hub Customers, the Company's own business data, and the systems that support the Service.

It applies to all staff, contractors, and any third party with access to Company systems or data, and covers the Service's infrastructure, applications, endpoints, and the physical/organisational environment around them.

2.Roles and Responsibilities

Technical Lead: [name or role · to be confirmed] owns the security of the Service's infrastructure and application, including access control, encryption, patching, and vulnerability management.

Data Protection Lead: [name or role · to be confirmed] owns this policy's alignment with data protection law and the Data Processing Agreement, and is notified of any security change that affects Employee Data handling.

All staff and contractors: responsible for following this policy, using approved tools and devices, and reporting suspected security issues immediately per the Incident & Data Breach Response Plan.

3.Asset and Data Classification

The Company classifies information to apply proportionate controls:

Classification
Restricted
Examples
Employee Data special category data (health, medical forms); authentication secrets, encryption keys
Baseline controls
Encrypted at rest and in transit; role-based access; access logged
Classification
Confidential
Examples
Other Employee Data; Customer account/billing data; internal financials
Baseline controls
Encrypted at rest and in transit; access limited to those who need it
Classification
Internal
Examples
Internal documentation, non-sensitive business communications
Baseline controls
Access limited to staff/contractors; not published externally
Classification
Public
Examples
Marketing materials, published Documentation
Baseline controls
No restriction

4.Access Control

4.1Access to systems and data is granted on the principle of least privilege — staff and contractors are given only the access necessary for their role, reviewed at least [quarterly · to be confirmed] and revoked promptly on role change or departure.

4.2Access to production systems and infrastructure (hosting console, database, deployment tooling) requires multi-factor authentication (MFA) without exception.

4.3Within the Service itself, Customer-configured roles (employee, manager, administrator) enforce that special category data (e.g. medical forms) is visible only to appropriately permissioned roles, per Customer configuration.

4.4Shared or generic accounts are not used for administrative access; each individual has their own credentials, so actions can be attributed.

4.5[Password policy for staff access · to be confirmed]

5.Encryption

5.1Data in transit is encrypted using TLS [1.2 or higher · to be confirmed] for all connections to the Service, including API and web traffic.

5.2Data at rest, including database storage and backups, is encrypted using AES-256.

5.3Encryption keys are managed [key management approach · to be confirmed] and access to keys is restricted and logged.

6.Infrastructure and Network Security

6.1The Service is hosted with Convex (database, file storage and back-end functions) and Vercel (website and application hosting), in the EU (Ireland).

6.2Production environments are logically separated from development and staging environments; test data used in non-production environments does not include real Employee Data unless anonymised or with explicit authorisation.

6.3Network access to infrastructure is restricted via [firewall rules / VPC configuration / provider-native controls · to be confirmed], with administrative interfaces not exposed to the public internet where avoidable.

6.4[DDoS protection / web application firewall approach · to be confirmed]

7.Application Security

7.1The Service is built following secure development practices, including input validation, protection against common vulnerabilities (e.g. those in the OWASP Top 10), and dependency vulnerability scanning as part of the build pipeline.

7.2Code changes are reviewed by at least one other engineer before deployment to production. [Code review and CI/CD process · to be confirmed]

7.3Secrets (API keys, database credentials) are stored in a secrets manager or equivalent, not committed to source control.

7.4[Penetration testing cadence · to be confirmed]

8.Vulnerability and Patch Management

8.1Operating systems, dependencies, and third-party libraries are monitored for known vulnerabilities and patched within timeframes proportionate to severity: [critical vulnerabilities within 7 days, high within 30 days · to be confirmed].

8.2Automated dependency scanning is run [continuously / on each build · to be confirmed] to flag vulnerable packages before they reach production.

9.Logging and Monitoring

9.1Access to production systems and key application events (e.g. authentication, permission changes, data exports) are logged, with logs retained for [12 months · to be confirmed] and protected from tampering.

9.2[Monitoring and alerting approach · to be confirmed]

9.3Logs are reviewed [periodically / upon alert · to be confirmed] and form part of the evidence base for any incident investigation under the Incident & Data Breach Response Plan.

10.Backup and Recovery

10.1[Backup frequency · to be confirmed] Backups are encrypted and stored [separately from primary systems / in a separate region · to be confirmed].

10.2Backup restoration is tested [at least annually · to be confirmed] to confirm backups are usable in a genuine recovery scenario.

10.3[Target Recovery Time Objective (RTO) and Recovery Point Objective (RPO) · to be confirmed]

11.Endpoint and Device Security

11.1Staff and contractor devices used to access Company systems or Employee Data must have disk encryption enabled, a locked screen after inactivity, and up-to-date operating system and security patches.

11.2[Approach to company-issued and personal (BYOD) devices, and any mobile device management (MDM) tooling · to be confirmed]

11.3Lost or stolen devices with access to Company systems must be reported immediately per the Incident & Data Breach Response Plan, so access can be revoked.

12.Third-Party and Sub-processor Security

12.1Before engaging a Sub-processor with access to Employee Data, the Technical Lead and Data Protection Lead assess its security posture (e.g. certifications such as ISO 27001 or SOC 2, security questionnaire, or public documentation) and ensure a written agreement is in place per the Data Processing Agreement.

12.2The current Sub-processor list is maintained in Annex 3 of the Data Processing Agreement and kept consistent with this policy.

13.Physical Security

13.1The Company does not operate its own data centres; physical security of infrastructure is the responsibility of Convex (hosted on Amazon Web Services) and Vercel, whose certifications include SOC 2 Type 2 (Convex and Vercel) and ISO 27001:2022 (Vercel).

13.2Where staff work from an office or co-working space, [physical access controls, or confirmation of remote-first working with no physical office handling Employee Data · to be confirmed].

14.Remote Working

Staff working remotely must connect to Company systems using approved, up-to-date devices, avoid using public/unsecured Wi-Fi for administrative access without a VPN or equivalent protection, and ensure screens are not left unattended in view of others when handling Employee Data.

15.Security Awareness and Training

All staff and contractors with system or data access complete security awareness training at induction and at least annually, covering this policy, phishing/social engineering awareness, and how to report a suspected incident.

16.Business Continuity

[Business continuity approach · to be confirmed]

17.Compliance and Audit

17.1This policy supports the Company's obligations under the Data Processing Agreement, UK GDPR, and any security commitments made to Customers (e.g. in Order documentation or security questionnaires).

17.2The Company will respond to reasonable Customer security questionnaires and support Customer audit rights as set out in the Data Processing Agreement.

17.3[Certifications held or targeted · to be confirmed]

18.Policy Violations

Failure to comply with this policy by staff or contractors may result in disciplinary action, up to and including termination of employment or contract, in accordance with the Company's disciplinary procedures.

19.Review

This policy is reviewed at least annually, after any significant security incident, or when there is a material change to the Company's infrastructure or Sub-processors, and is approved by [director or role · to be confirmed]. All bracketed items must be completed and kept current, particularly following any change of hosting provider or architecture.

20.Contact

Questions about this policy should be directed to:

Build Your Vision Ltd
71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom
Technical Lead: [name · to be confirmed] — Email: [email · to be confirmed]
Data Protection Lead: [name · to be confirmed] — Email: info@buildyourvision.co.uk
Website: byvpeoplehub.com