Information Security Policy

Our information-security programme is built and operated in alignment with ISO/IEC 27001:2022. This policy sets out the controls we apply to how we build, host and operate our own systems and the software we deliver to clients.

1. Purpose

The confidentiality, integrity and availability of information — our own and our clients’ — is fundamental to how we operate. This policy sets out the principles, controls and responsibilities that govern information security across Software and AI Services Ltd, and applies to every engagement, every employee or contractor working with us, and every system we own, host or manage.

2. Alignment and scope

Our information-security controls are designed to align with ISO/IEC 27001:2022 Annex A and, where relevant to a specific client system, additional frameworks:

ISO/IEC 27001 Annex A — organisational, people, physical and technological controls.
SOC 2 (Trust Services Criteria CC6 and CC7) — logical access controls and system monitoring.
UK GDPR / Data Protection Act 2018 — Articles 15–18 (data subject rights), Article 32 (security of processing).
HIPAA § 164.312 — technical safeguards, where our work touches protected health information (for example, the Halo Connected Health platform).

3. Governance and responsibility

Overall accountability for information security rests with the Director. All employees and contractors are individually responsible for following this policy and for reporting suspected security events promptly. Security training and reminders are provided at onboarding and refreshed at least annually.

4. Access control

Access to systems and data follows the principle of least privilege — people are granted only the access they need to perform their role, for only as long as they need it.

Named user accounts and role-based access control (RBAC) on every system.
Multi-factor authentication for every administrator account and every remote-access service that supports it.
Regular review of access rights; prompt revocation when a role ends.
Separation of duties between development, deployment and production access on client systems.

5. Encryption

In transit: TLS 1.2 or higher on every public endpoint. Legacy protocols are disabled.
At rest: encryption at rest is enabled by default for databases, object stores and backups on the systems we build and operate.
Credentials: secrets are stored in dedicated secret managers (AWS SSM Parameter Store, AWS Secrets Manager or equivalent), never in source control.

6. Logging, monitoring and audit

Security-relevant events are logged to an append-only audit trail. Both successful and denied access decisions are recorded (denials matter as much as grants — a spike of denials is how you detect probing). Where we build client systems handling personal or regulated data, this audit trail is designed to be tamper-resistant and retained for compliance-relevant periods.

Application, infrastructure and access logs are centralised and time-synchronised.
Automated monitoring and alerting on health, security and integrity signals.
Incident detection and escalation are on-call channels we actually read.

7. Secure software development lifecycle

Trunk-based development on short-lived branches, with squash-merge to a protected main branch.
Peer or LLM-assisted review of every change before merge.
Automated tests at three layers (unit, integration, end-to-end) with browser tests for user-facing changes.
Client- and server-side validation on every user input; the server is the source of truth.
Destructive operations refuse safely with a human-readable reason and check for dependent records before running.
A manual approval gate before production deploys, on every project, without exception.

8. Vulnerability management and patching

Automated dependency scanning; timely upgrades of libraries with known vulnerabilities.
OS and runtime patching on managed infrastructure.
Coordinated disclosure — please report suspected vulnerabilities responsibly to privacy@softwareandaiservices.co.uk. We will acknowledge within one business day and work with you on remediation.

9. Data classification and handling

Data is handled in proportion to its sensitivity:

Public — non-sensitive; may be shared freely.
Internal — company-internal; not published externally.
Confidential — client data, project information, personal data (see Privacy Policy).
Special category / regulated — health and other regulated data; handled with additional controls (audit, encryption, restricted access, no non-production copies without written approval).

10. Data subject rights and deletion

We support the UK GDPR data-subject rights (Articles 15–22) — access, rectification, erasure, restriction, portability and objection — via a documented request flow. Erasure on regulated systems follows a soft-delete-then-audited-hard-delete pattern so we can prove the deletion happened.

11. Physical and endpoint security

Company devices are full-disk-encrypted, patched and require a strong screen lock.
Remote-work devices connect to client systems only via authenticated, encrypted channels.
Loss or theft of a company device must be reported immediately so access can be revoked.

12. Backups and recovery

Every system of record we operate is backed up on a defined schedule.
Restore procedures are tested — a backup that has never been restored from is an unverified claim.
Retention matches the sensitivity of the data and any regulatory duty; where relevant, immutable storage (for example, S3 Object Lock) is used.

13. Third parties and suppliers

We use a small number of well-established, contractually-committed service providers (hosting, cloud infrastructure, issue tracking, email). We select providers with credible security postures and put appropriate contracts and data processing agreements in place before using them for anything containing client data.

14. Incident response

Security incidents are handled under our incident response process — triage, containment, communication and blameless postmortem.

Sev 1 (data leak, safety-relevant failure, or full outage) — immediate response, hotfix, postmortem required.
Sev 2 (major broken functionality with no workaround) — same-day fix, postmortem required.
Sev 3 (degraded or broken with workaround) — normal prioritised fix flow.
Where a personal-data breach is confirmed, we assess whether ICO notification is required within the UK GDPR 72-hour window and notify affected data subjects where the risk requires it.

15. Automation and AI agents

We use AI-assisted tooling to accelerate development, reviews and operations. Automation is scoped to the smallest useful set of tools per channel, and irreversible actions — production deploys and infrastructure changes, money movement, contract or document signing, external messages to real customers, and adding a new dependency — always require an explicit human decision.

16. Policy review

This policy is reviewed at least annually and after any material incident or change of scope. Substantive changes are dated and published on this page.

17. Contact

Security enquiries, vulnerability reports and audit questions: privacy@softwareandaiservices.co.uk.

Software and AI Services Ltd is registered in Northern Ireland, company number NI732919. Registered office: 98 Larne Road, Ballyclare, Northern Ireland, BT39 9UD. Policy last updated: August 2026.