Discuss a project
Legal

Information Security Policy Summary

A published summary of how we handle information security. Detail specific to an engagement is answered through that engagement's own assurance process.

ASTRI DEVS LTD is the controller of personal data described in this document, unless it says otherwise.

Effective from 19 August 2026. Last reviewed 19 August 2026. Review cycle: annually.

Purpose and scope

This summary covers information security across ASTRI DEVS LTD's own systems and the client work it delivers. It is a summary: it deliberately does not describe infrastructure topology, internal addressing, credential names, tooling detail or specific findings, because publishing those helps an attacker more than it reassures a buyer.

Certification position

ASTRI DEVS LTD holds no Cyber Essentials, Cyber Essentials Plus, ISO 27001 or SOC 2 certification, and makes no claim to any. Our controls are designed with established security principles in mind and are described here accurately rather than dressed up as an accreditation.

Responsibility

Responsibility for information security sits with the company's directors and is not delegated to a supplier. Security decisions that affect a client engagement are raised with the client rather than taken unilaterally.

Access control

  • Access is granted on a least-privilege basis, for the period the work requires.
  • Multi-factor authentication is required on administrative and email accounts.
  • Credentials are unique per service and held in a password manager, never shared in plain text.
  • Access to a client's systems is granted by the client, through the client's own process, and is handed back at the end of an engagement.
  • Production access is separated from routine development access.

Devices and endpoints

  • Devices used for client work have full-disk encryption enabled.
  • Operating systems and applications are kept current with security updates.
  • Devices are screen-locked and require authentication.
  • Client data is not stored on removable media.

Secure development

  • Dependencies are tracked and audited for known vulnerabilities as part of the build.
  • Secrets are held in the deployment platform's secret storage and injected as environment variables. Credentials are not committed to source control, and repositories are checked for accidental commits.
  • Changes are reviewed before reaching a shared branch, with automated checks on every change.
  • Development, staging and production are separated, with separate credentials. Production personal data is not copied into development environments; test data is synthetic or anonymised.
  • Input is validated on the server, never only in the browser.
  • Data in transit is protected with TLS.

Handling client data

  • Where we process personal data for a client, the client is the controller, we act on their documented instructions, and the terms are set out in a written data processing agreement.
  • We take the minimum access to client data that the work requires.
  • At the end of an engagement, client data in our possession is returned or deleted according to the contract, and access is removed.

Suppliers and subprocessors

Suppliers and subcontractors with access to client systems or data are checked before engagement and are bound by written confidentiality and data protection obligations. Where a client requires approval of subprocessors, we obtain it before granting access rather than afterwards.

Incident response

  • Suspected incidents are triaged immediately by a director, who decides on containment before investigation continues.
  • Where an incident affects a client's systems or data, the client is notified without undue delay with what is known at the time, and is kept informed as the picture develops. We do not wait for a complete account before telling a client something has happened.
  • Where a personal data breach meets the threshold, it is reported to the Information Commissioner's Office within 72 hours of becoming aware of it, and to affected individuals where required.
  • Incidents are recorded, including those that did not meet a reporting threshold.

Continuity and backup

Source code, configuration and business records are held in managed services with their own redundancy, and are recoverable independently of any single device. Systems we build are designed with a backup and recovery position agreed with the client as part of delivery rather than assumed.

Continuity arrangements, key-person risk and recovery objectives are discussed during due diligence. We do not publish tested recovery metrics, because we do not have tested figures and inventing them would be worse than saying so.

Supplier security questionnaires

We complete supplier security questionnaires as part of procurement, answered against the specific engagement. Send yours with the procurement reference to info@astridevs.co.uk. Where an answer is "no" or "not yet", it will say so.

Vulnerabilities in systems we operate can be reported under our responsible disclosure policy.