Legal / Compliance

ISO/IEC 27001 controls alignment.

A self-assessment of Hydrate's security controls against the ISO/IEC 27001:2022 Annex A framework. Not yet certified. Written for procurement reviewers and Enterprise customers conducting vendor security assessments.

Version 1.0 · Effective: 2026-04-25 · Next review: 2027-04-25 · Standard reference: ISO/IEC 27001:2022 · Owner: Seamus Waldron, Sedasoft Ltd

Certification status: not yet certified. ISO/IEC 27001 certification requires an accredited certification body to audit the ISMS and issue a certificate with a three-year validity and annual surveillance audits. Sedasoft is aligning controls to the standard in preparation for certification. Enterprise customers requiring a certified ISMS should contact [email protected] to discuss timelines and interim arrangements.

1. ISMS scope

The ISMS scope encompasses:

Hydrate software (Free, Pro, Team, Enterprise tiers): development, build, distribution, and support
Hydrate Enterprise server: development, deployment, and operation on customer infrastructure
Sedasoft Ltd development infrastructure: developer devices, GitHub, Cloudflare, deployment server
Third-party service integrations: OpenAI, Anthropic, Voyage AI, Cloudflare, GitHub, Stripe

Out of scope: customer's own infrastructure on which the Enterprise server is deployed. Customers are responsible for their own ISMS within their deployment environment.

The architecture is local-first: customer session data does not flow through Sedasoft infrastructure in any tier. This substantially reduces the information assets held by Sedasoft and narrows the ISMS boundary.

2. Annex A controls mapping

ISO/IEC 27001:2022 Annex A contains 93 controls across four themes. The assessment below covers controls relevant to Sedasoft's scale and architecture. Controls marked "Not applicable" are excluded with documented rationale.

A: Organisational controls

5.1: Information security policies

Implemented

Security policy, data handling, incident response, vendor risk, and access review are published, versioned, and annually reviewed. See Security Policy.

5.2: Information security roles

Implemented

Seamus Waldron is the designated ISMS owner, security policy owner, and incident response lead. All compliance documents identify an owner.

5.3: Segregation of duties

Partial

Two founding members hold access. Full segregation of duties is not achievable at current team size. Compensating control: all production deployments are version-controlled; no unilateral action can be hidden.

5.4: Management responsibilities

Implemented

Founding team actively maintains security documentation, responds to disclosures, and reviews compliance docs on schedule.

5.5: Contact with authorities

Partial

GDPR regulator contact (ICO) is identified in the incident response plan. EU AI Act competent authority contacts are being established ahead of August 2026.

5.7: Threat intelligence

Partial

govulncheck provides Go-ecosystem CVE tracking. No formal threat intelligence feed. Responsible disclosure channel is open.

5.9: Information asset inventory

Partial

Data classification documented in Data Handling (Public → Restricted schema). No formal asset register with owners; ISMS boundary defines scope implicitly.

5.10: Acceptable use

Implemented

Enterprise Terms of Service and EU AI Act assessment define acceptable and prohibited uses. Developer usage policies for internal tooling are informal.

5.12: Classification of information

Implemented

Four-tier classification (Public, Internal, Confidential, Restricted) with handling rules documented in Data Handling.

5.13: Labelling of information

Partial

Classification tiers are defined. Automated labelling of stored data assets is not implemented; classification is applied at the policy level.

5.15: Access control

Implemented

Named access only, least privilege, quarterly review, 24-hour offboarding revocation. API authentication (JWT + API key) with RBAC. Access inventory available to Enterprise customers on request.

5.17: Authentication

Implemented

GitHub and Cloudflare use hardware FIDO2 keys. Production SSH via Tailscale device auth. API authentication via JWT (HS256) and API key with RBAC enforcement.

5.18: Access rights

Implemented

Quarterly access review process documented. Revocation on role change or departure. No persistent shared credentials.

5.19: Information security in supplier relationships

Implemented

DPA status, breach notification SLAs, and risk ratings for all sub-processors documented in Vendor Risk. Annual review.

5.20: Supplier agreements

Implemented

DPAs are in place or confirmed unnecessary for each sub-processor. Enterprise customers receive a Data Processing Agreement as Schedule 2 of the Enterprise agreement.

5.23: Security in cloud services

Implemented

Cloud services used: Cloudflare Pages (distribution, zero customer data), GitHub (source code), Stripe (billing). None hold session content. Risk rated in Vendor Risk.

5.24: Information security incident management

Implemented

P1-P4 severity classification, five-step procedure, GDPR 72-hour reporting obligation, incident log format. See Incident Response.

5.26: Lessons learned from incidents

Partial

Incident log includes post-incident review section. No formal post-incident review process beyond the log template.

5.29: Business continuity

Gap

Deployment recovery procedure is documented (binary replacement). No formal BCP, RPO, or RTO targets. Business continuity planning is on the roadmap.

5.31: Legal and regulatory requirements

Implemented

EU AI Act assessment, GDPR data handling and DPIA, UK GDPR via ICO registration, EU representative assessment in progress.

5.33: Protection of records

Implemented

Audit log retention: configurable in Enterprise server, default 90 days. GDPR records of processing documented. Hydrate retrievals ledger retained per configurable policy.

5.36: Compliance with policies

Implemented

Policy exceptions require documented written approval. Annual review of all compliance documents.

B: People controls

6.1: Screening

Partial

Founding team only. No formal screening process; no external employees or contractors with system access.

6.2: Terms and conditions of employment

Partial

Confidentiality obligations are set out in founder agreements. No formal ISMS acknowledgement process for personnel beyond founding team.

6.3: Awareness, education, and training

Partial

Founding team maintains security and compliance documentation directly. No formal security awareness training programme.

6.4: Disciplinary process

N/A

Two-person founding team. No formal disciplinary process applies.

6.5: Responsibilities after termination

Implemented

Access revoked within 24 hours of departure. Shared credentials rotated. Documented in security policy.

6.7: Remote working

Implemented

All work is remote. Full-disk encryption on developer devices (macOS FileVault). Tailscale for production server access. Device lock policy in place.

6.8: Information security event reporting

Implemented

Responsible disclosure at [email protected]. Internal incident log. 48-hour acknowledgement SLA.

C: Physical controls

7.1: Physical security perimeter

Implemented

Production deployment server is in a physically secured, access-controlled location. Remote access requires device authentication; SSH is not exposed to the public internet.

7.2: Physical entry controls

Implemented

Production server is in a private residential or office location accessible only to named individuals. No shared co-location facility; physical access is inherently restricted.

7.8: Equipment siting and protection

Implemented

Developer devices use full-disk encryption (macOS FileVault). Devices are locked when unattended.

7.12: Cabling security

N/A

Production server is a single consumer device. Structured cabling controls are not applicable at this scale.

7.14: Secure disposal

Partial

macOS Secure Erase is used when decommissioning developer devices. No formal media disposal procedure documented.

D: Technological controls

8.2: Privileged access rights

Implemented

Least-privilege principle applied. Admin rights granted only where required. Quarterly review of access rights. Access inventory available to Enterprise customers on request.

8.3: Information access restriction

Implemented

The Enterprise server enforces RBAC (read / write / admin) per connector. The local Hydrate server enforces a per-server API key. All /api/v1/* routes require authentication.

8.4: Access to source code

Implemented

GitHub repositories require authentication. No public write access. Third-party contributors are not granted repository access.

8.5: Secure authentication

Implemented

Hardware FIDO2 for GitHub and Cloudflare. Tailscale device auth for production SSH. JWT (HS256, 24-hour expiry) + API key for application authentication.

8.7: Protection against malware

Implemented

govulncheck scans dependencies on CI. SHA-256 checksums on published binaries allow integrity verification. macOS Gatekeeper and XProtect active on developer devices.

8.8: Management of technical vulnerabilities

Implemented

govulncheck blocks release on known vulnerabilities. CVSS ≥ 9.0 patched within 7 days; High within 30 days. Docker base images rebuilt monthly.

8.9: Configuration management

Implemented

All configuration is in version control (Go modules, Dockerfile, docker-compose.yml, install.sh). Infrastructure changes are tracked via Git commit history.

8.10: Information deletion

Implemented

Enterprise server: DELETE /api/v1/users/{id} performs right-to-be-forgotten deletion across all tables. Hydrate: hydrate uninstall --purge removes all local data. Retention periods documented in Data Handling.

8.11: Data masking

Partial

Secrets scrubbing in session capture removes API keys, tokens, and PEM blocks before storage. The Enterprise server user memory eligibility filter rejects PII facts. No column-level masking on PostgreSQL tables.

8.12: Data leakage prevention

Implemented

Secrets scrubber prevents accidental LLM transmission of credentials. Local-first architecture prevents Sedasoft receiving customer session content in any tier.

8.13: Backup

Partial

Hydrate Pro: hydrate backup creates encrypted local backups. Enterprise server: no automated PostgreSQL backup is managed by Sedasoft:this is on customer infrastructure. Customers should implement their own backup policy.

8.15: Logging

Implemented

Enterprise server: auth_audit table with event type, actor, IP, user-agent, outcome; 180-day retention. Hydrate: per-handler audit log, JSONL rotation for SIEM export, configurable retention.

8.16: Monitoring activities

Partial

Prometheus metrics (HTTP latency, RAG query duration, OpenAI calls) and /health, /ready endpoints are in place. Automated alerting is not yet configured.

8.20: Networks security

Implemented

HSTS, Content-Security-Policy, X-Frame-Options, CORS restrictions, and Cross-Origin-Resource-Policy are applied to all Enterprise server responses. Hydrate-server uses HTTP on localhost only; remote Enterprise deployments should terminate TLS at the load balancer.

8.23: Web filtering

Implemented

SSRF defence: BYOK LLM/embed endpoint URLs are validated against a private-IP-range blocklist on startup. Private IP ranges (10.x, 172.16.x, 192.168.x, 127.x, link-local) and non-HTTP(S) schemes are rejected.

8.25: Secure development lifecycle

Implemented

CI pipeline (GitHub Actions) runs govulncheck, build tests, unit tests. No code lands in production without passing CI. Binary signing and SHA-256 checksums on releases.

8.26: Application security requirements

Implemented

Input size limits (10 MiB body limit), UUID parsing, enum validation, parameterised queries (no SQL injection risk), rate limiting, injection defence framing in fact injection. Risk assessment identifies and mitigates prompt injection.

8.28: Secure coding

Implemented

Go's type system, pgx parameterised queries, and crypto/rand for nonce generation. AES-256-GCM for field-level encryption. Internal packages follow memory-safe Go idioms.

8.29: Security testing

Partial

Unit tests, build tests, govulncheck on CI. No third-party penetration test has been conducted. Responsible disclosure channel is open; no confirmed external findings to date.

8.30: Outsourced development

N/A

No outsourced development. All code is authored or reviewed by the founding team.

8.32: Change management

Implemented

All changes via Git. CI required to pass before release. Deployment procedure documented. Rollback is binary replacement with previous release artifact.

8.34: Protection of information systems during audit testing

Partial

No audit testing has been conducted yet. When penetration testing is commissioned, it will be scheduled during low-traffic periods and scoped to avoid production data access.

3. Material gaps (as of 2026-04-25)

The following items represent the largest gaps between current practice and full ISO/IEC 27001:2022 conformance. They are documented here for transparency.

5.29: Business continuity

No formal Business Continuity Plan (BCP) or Disaster Recovery Plan (DRP) with tested RPO and RTO targets. Recovery procedures for Enterprise server deployment exist but are not formalised or tested.

Target: Q3 2026

8.13: Backup (Enterprise server)

The Enterprise server runs on customer infrastructure; Sedasoft does not manage backups. Customers must implement their own backup policy. Sedasoft provides guidance but no managed backup service.

Customer responsibility; guidance to be added to Enterprise docs

8.16: Automated alerting

Prometheus metrics and audit logs exist but no automated alerting rules or SLO dashboards are configured. Anomaly detection is currently reactive.

Target: Q3 2026

8.29: Penetration testing

No third-party penetration test has been conducted. The responsible disclosure programme is active and no confirmed external vulnerabilities are outstanding.

Target: within 12 months of Enterprise GA

Certification audit

ISO/IEC 27001 certification requires an accredited certification body to audit the ISMS over a minimum observation period. This self-assessment is a preparatory step, not a certificate.

Target: 2027 (Enterprise pipeline dependent)

4. Cryptography controls summary

This section summarises the cryptographic controls in use (relevant to Annex A 8.24, Cryptography Policy).

Encryption at rest: Hydrate facts (Free/Pro)

AES-256-GCM field-level encryption. Key derived from SHA-256(install_id + compile-time seed fragments). Nonce: 12-byte random per write via crypto/rand. Implemented in internal/obfuscate.

Encryption at rest: Enterprise server PostgreSQL

Not column-encrypted by Sedasoft. Customer's OS-level or cloud storage encryption applies. Enterprise customers in regulated contexts should enable disk encryption at the host level.

Encryption in transit: Enterprise server

HSTS enforced (Strict-Transport-Security: max-age=63072000; includeSubDomains). All external API calls (OpenAI, Anthropic, Voyage) use HTTPS.

Encryption in transit: Hydrate-server (Free/Pro)

HTTP on localhost (127.0.0.1) by default. TLS is not managed by hydrate-server. Enterprise remote deployments should terminate TLS at a reverse proxy or load balancer.

API authentication tokens

JWT signed with HS256 (24-hour expiry). API keys are randomly generated (crypto/rand, 48 hex chars). Stored in PostgreSQL (Enterprise server) or SQLite meta table (local Hydrate).

Binary signing

Published binaries are signed with a code signing certificate and SHA-256 checksums are published alongside each release for integrity verification.

Hydrate backup bundles (Pro)

Project export bundles are encrypted with a user-supplied passphrase before writing to disk. Sedasoft never receives or processes backup content.

5. Enterprise customers

Enterprise customers deploying the Hydrate Enterprise server on their own infrastructure bear responsibility for the ISMS controls within their deployment boundary. Sedasoft provides:

Technical documentation (system architecture, data flows, API reference)
Data Processing Agreement (Schedule 2 of the Enterprise agreement)
EU AI Act customer obligations guidance (Section 11 of the EU AI Act assessment)
GDPR Article 15/17/20 endpoints for data subject rights
Audit log export for SIEM integration

Enterprise customers with ISO 27001 certification requirements for their own vendors should contact us to discuss the current controls posture, planned certification timeline, and whether compensating controls in their own deployment address specific requirements.

[email protected]: Enterprise and pre-sales
[email protected]: Compliance and legal

Version 1.0 · This is a self-assessment, not a certified audit. Controls are reviewed annually. Next review: 2027-04-25.