Control coverage
Klyrix is not yet certified to ISO/IEC 27001:2022 or SOC 2 Type 2. The matrix below maps every applicable control to its implementation status and references the underlying evidence (code paths, migrations, policies). Data is rendered server-side from lib/compliance/control-registry.ts — the single source of truth. JSON export: /api/internal/compliance/coverage.
Implementation status reflects what is live in the codebase today. Certification requires (a) an accredited external auditor, (b) a multi-month observation window for SOC 2 Type 2, and (c) an independent penetration test. Vendor selection for both is in progress.
ISO 27001:2022 — Annex A
60%
55 implemented · 33 partial · 3 planned · 2 N/A
of 91 applicable / 93 total
SOC 2 Trust Services Criteria
90%
46 implemented · 5 partial · 0 planned · 0 N/A
of 51 applicable / 51 total
ISO 27001:2022 Annex A — 93 controls across 4 domains
Organizational — 37 controls
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| A.5.1 | Policies for information security | Implemented | Master ISMS policy + 9 supporting compliance docs. 2 references |
| A.5.2 | Information security roles and responsibilities | Implemented | Roles documented in ISMS scope + working group composition. 2 references |
| A.5.3 | Segregation of duties | Partial | Platform admin vs system owner vs farm member separation; SoD in role matrix. Role separation is enforced in the application (platform admin / system owner-member / farm manager-admin-observer), but there is no dual control for code changes and deploys: single maintainer, no mandatory second-person review (K-361). Full SoD matrix planned. 2 references |
| A.5.4 | Management responsibilities | Implemented | Quarterly management review template + sign-off blocks. 1 reference |
| A.5.5 | Contact with authorities | Partial | VERBİS kayıt + KVKK kurumu temas listesi hazır; ENISA / national CERT direct contact not yet established. 2 references |
| A.5.6 | Contact with special interest groups | Partial | Engineering team monitors OWASP, CVE feeds; formal membership pending. 1 reference |
| A.5.7 | Threat intelligence | Partial | Dependabot + npm audit on every push (pre-push gate) + weekly local strict npm audit and OWASP ZAP baseline; commercial TI feed not subscribed. 2 references |
| A.5.8 | Information security in project management | Implemented | Change management policy + sprint pre-flight security review. 1 reference |
| A.5.9 | Inventory of information and other associated assets | Implemented | ROPA (GDPR Art. 30) + data retention table = asset inventory. 2 references |
| A.5.10 | Acceptable use of information and other associated assets | Implemented | Public Acceptable Use Policy + DPA includes processor AUP. 1 reference |
| A.5.11 | Return of assets | Implemented | Termination procedure includes credential revocation + data return. 1 reference |
| A.5.12 | Classification of information | Partial | Data classified by category (auth/billing/audit/DVR/telemetry); retention drives handling. Data is grouped by category and retention drives handling, but there is no formal classification scheme (sensitivity levels with handling rules per level) yet; planned. 2 references |
| A.5.13 | Labelling of information | Partial | audit_logs schema enforces action+target_kind+target_name labels. Labels exist only as structured audit_logs fields; there is no information labelling tied to a classification scheme (A.5.12 is partial). UI label rollout planned. 2 references |
| A.5.14 | Information transfer | Implemented | DPA template + SCCs for cross-border transfer (US sub-processors). 2 references |
| A.5.15 | Access control | Implemented | RLS Phase 2 + scope-based internal auth + platform/system/farm role matrix. 3 references |
| A.5.16 | Identity management | Implemented | Admin identity = Supabase Auth + auth_user_id; lifecycle via SCIM 2.0 + HR webhook. 2 references |
| A.5.17 | Authentication information | Implemented | Passwords stored as bcrypt hashes (Supabase Auth); MFA TOTP, a native Supabase Auth factor whose secret Supabase Auth stores and manages; 8 internal scope secrets read from environment variables. 2 references |
| A.5.18 | Access rights | Implemented | Monthly access snapshot (D-112) + quarterly access review cron (D-120 Faz 4). 2 references |
| A.5.19 | Information security in supplier relationships | Implemented | 7-vendor sub-processor list + annual SOC2 collection cron. 2 references |
| A.5.20 | Addressing information security within supplier agreements | Implemented | DPA template requires sub-processor security commitments + audit rights. 1 reference |
| A.5.21 | Managing information security in the ICT supply chain | Partial | Dependabot opens weekly npm update PRs (backoffice + worker), merged locally through the pre-push gate; npm audit baseline on every push; SBOM publication pending. 2 references |
| A.5.22 | Monitoring, review and change management of supplier services | Implemented | 2 references |
| A.5.23 | Information security for use of cloud services | Implemented | All cloud services enumerated in sub-processor list + ROPA + DPA. 2 references |
| A.5.24 | Information security incident management planning and preparation | Implemented | 2 references |
| A.5.25 | Assessment and decision on information security events | Implemented | Sentry APM 14 D-119 area tags + log-drain + security_event_log. 3 references |
| A.5.26 | Response to information security incidents | Implemented | 2 references |
| A.5.27 | Learning from information security incidents | Implemented | 2 references |
| A.5.28 | Collection of evidence | Implemented | audit_logs append-only partitioned + D-112 monthly evidence snapshots. 2 references |
| A.5.29 | Information security during disruption | Implemented | 1 reference |
| A.5.30 | ICT readiness for business continuity | Implemented | D-059 Recovery Orchestrator 6-step state machine + tabletop exercises. 2 references |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Implemented | 3 references |
| A.5.32 | Intellectual property rights | Implemented | ToS + license declarations in source; no copyleft in production deps. 2 references |
| A.5.33 | Protection of records | Implemented | audit_logs append-only at DB layer; retention enforced via cron. 2 references |
| A.5.34 | Privacy and protection of PII | Implemented | 3 references |
| A.5.35 | Independent review of information security | Planned | Internal audit program documented; external pentest vendor selection in progress. 1 reference |
| A.5.36 | Compliance with policies, rules and standards for information security | Implemented | 2 references |
| A.5.37 | Documented operating procedures | Implemented | 2 references |
People — 8 controls
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| A.6.1 | Screening | Partial | Background check process documented for hires; not yet automated. 1 reference |
| A.6.2 | Terms and conditions of employment | Partial | NDA template + confidentiality clauses standard; signed copies tracked offline. 1 reference |
| A.6.3 | Information security awareness, education and training | Partial | Training log table and operator entry page are in place; the annual security awareness programme has not been launched yet (TP-05, target 2026-Q4). 2 references |
| A.6.4 | Disciplinary process | Implemented | 1 reference |
| A.6.5 | Responsibilities after termination or change of employment | Implemented | Termination triggers credential revoke + WG quarantine + AD deactivation. 2 references |
| A.6.6 | Confidentiality or non-disclosure agreements | Implemented | 1 reference |
| A.6.7 | Remote working | Partial | WG handshake-gated firewall + one-device strict + mesh hub-spoke (HAProxy-1). The evidence covers the WireGuard entry layer Klyrix operates for its customers' remote users. For Klyrix's own personnel working remotely there is no remote-working policy and no documented endpoint baseline yet (planned); personnel devices are not enforced or evidenced (see A.7.9). 2 references |
| A.6.8 | Information security event reporting | Implemented | Vulnerability disclosure security@klyrix.com + 72h acknowledgement SLA. 2 references |
Physical — 14 controls
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| A.7.1 | Physical security perimeters | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Perimeter controls of the Klyrix office are not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.2 | Physical entry | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Entry controls of the Klyrix office are not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.3 | Securing offices, rooms and facilities | Planned | The Klyrix office is in ISMS scope; its security measures are not yet documented or evidenced in the ISMS (office physical security policy planned, TP-11). |
| A.7.4 | Physical security monitoring | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Physical security monitoring of the Klyrix office is not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.5 | Protecting against physical and environmental threats | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Protection of the Klyrix office against physical and environmental threats is not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.6 | Working in secure areas | N/A | No secure area is designated in the office: the ISMS asset inventory places all infrastructure assets in the cloud (ISMS scope §3.2, §5.1), and Klyrix personnel do not work in sub-processor data-centre secure areas. 1 reference |
| A.7.7 | Clear desk and clear screen | Planned | No clear desk / clear screen rule is documented yet; planned together with the office physical security policy (TP-11). |
| A.7.8 | Equipment siting and protection | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Siting and protection of Klyrix office equipment and personnel devices are not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.9 | Security of assets off-premises | Partial | Users connect through a per-user WireGuard connect package; RDS hosts accept RDP only from mesh subnets (handshake-gated firewall). Klyrix devices used outside the office: disk encryption and device management are not enforced or verified; no evidence (MDM planned). End-user devices are customer assets and out of ISMS scope (00-isms-scope §4.3). 2 references |
| A.7.10 | Storage media | Partial | Backups leave the host restic-encrypted (e.g. AD systemstate to the off-site backup repository); media retention per the data retention policy. RDS sessions: drive / USB redirection can be switched off per system and drive access hidden per role. Removable media handling (use, transport, disposal) for Klyrix personnel devices and the office is not documented or evidenced (TP-11). 4 references |
| A.7.11 | Supporting utilities | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Supporting utilities of the Klyrix office (power, network) are not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.12 | Cabling security | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Cabling in the Klyrix office is not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.13 | Equipment maintenance | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). Maintenance of Klyrix office equipment and personnel devices is not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
| A.7.14 | Secure disposal or re-use of equipment | Partial | Data-centre portion inherited from sub-processors (SOC 2 / ISO 27001 attested; annual report review per the vendor management policy). A disposal / re-use procedure for Klyrix office equipment and personnel devices is not yet documented or evidenced in the ISMS; the office is in ISMS scope (office physical security policy planned, TP-11). 2 references |
Technological — 34 controls
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| A.8.1 | User endpoint devices | Partial | Per-user lockdown matrix (4 role × 16 settings) + AtLogon HKCU registry apply. The lockdown matrix is enforced on RDS sessions (role profiles + per-user overrides, applied to HKCU at logon); for Klyrix personnel devices (in ISMS scope) there is no evidence of disk encryption or device management; MDM planned (K-385). End-user devices are customer assets and out of ISMS scope (00-isms-scope §4.3). 2 references |
| A.8.2 | Privileged access rights | Implemented | JIT elevation (D-119) + platform_admin tight scoping + 8 internal scope env. 2 references |
| A.8.3 | Information access restriction | Implemented | RLS Phase 2 — all tenant-scoped tables have tight policies; service_role bypass + platform_admin layer. 3 references |
| A.8.4 | Access to source code | Partial | Private GitHub repository on a personal account; a single collaborator (the maintainer). Single maintainer; no branch protection or enforced code review on main. 2 references |
| A.8.5 | Secure authentication | Implemented | MFA TOTP mandatory + SSO/SAML for enterprise + SCIM 2.0 + sha256-fingerprinted API tokens. 1 reference |
| A.8.6 | Capacity management | Implemented | D-078 tenant quota + per-tenant rate limit + 20 vendor breakers + DLQ. 2 references |
| A.8.7 | Protection against malware | Partial | Windows-side Defender enforced via lockdown matrix; Linux EDR (Wazuh/Velociraptor) D-119 K3-A deployed via kill-switch when infra ready. 2 references |
| A.8.8 | Management of technical vulnerabilities | Implemented | Dependabot + npm audit on every push + weekly local strict npm audit and OWASP ZAP baseline + 72h disclosure SLA. 3 references |
| A.8.9 | Configuration management | Implemented | security_config (28 keys) + scale_config + Ansible roles for server config. 3 references |
| A.8.10 | Information deletion | Implemented | DSR erasure flow + retention cron + tenant data hard-delete on subscription end (D-074). 2 references |
| A.8.11 | Data masking | Partial | DVR opt-in only; PII redaction in audit_logs detail jsonb is per-handler responsibility. 1 reference |
| A.8.12 | Data leakage prevention | Partial | RLS Phase 2 + supabaseAdmin tenant-scope rule (D-076) + tenant_quota_usage + audit_logs. Tenant isolation (RLS Phase 2 + supabaseAdmin tenant-scope rule, D-076) limits cross-tenant leakage; there is no dedicated DLP control (content inspection / egress policy) yet; planned. 3 references |
| A.8.13 | Information backup | Implemented | User vault + app state to an off-site bucket (every 15 min) + daily AD systemstate + cold DB + vault snapshot (daily by default; client-side AES-256-GCM mandatory for new sets; a snapshot carrying vault secrets is never written without encryption); scope guard backup_verify. 4 references |
| A.8.14 | Redundancy of information processing facilities | Partial | Supabase + Vercel native HA; multi-region read replica scaffold dormant (D-097 F2+F3 work). 2 references |
| A.8.15 | Logging | Implemented | audit_logs append-only partitioned + error_logs + Vercel log-drain ingest. 3 references |
| A.8.16 | Monitoring activities | Implemented | Sentry APM with 14 D-119 area tags + monthly evidence snapshots + status.klyrix.com. 2 references |
| A.8.17 | Clock synchronization | Implemented | Linux servers: chrony with NTS-authenticated sources + drift reporting (D-119 K3-D); Windows servers: w32tm synced to time.windows.com (plain NTP, no NTS). 3 references |
| A.8.18 | Use of privileged utility programs | Implemented | 2 references |
| A.8.19 | Installation of software on operational systems | Implemented | App catalog (200+ packages) + library-store-grant flow + demand-driven install (D-046/D-045). 2 references |
| A.8.20 | Networks security | Implemented | WG mesh hub-spoke + east-west segmentation (D-119 kill-switch) + CF WAF. 2 references |
| A.8.21 | Security of network services | Implemented | WG handshake-gated firewall (recovery mode if handshake fails) + middleware security headers. 2 references |
| A.8.22 | Segregation of networks | Implemented | Tenant-isolated WG namespaces + east-west segmentation kill-switch ready. 2 references |
| A.8.23 | Web filtering | Partial | Internet access can be allowed or blocked per user and shift window at the WireGuard hub (staff roles, when the shift gate is enabled: internet_allowed → vds_inet_off drop); there is no site / URL / category filtering (the lockdown matrix has no URL setting); outbound proxy / DNS filtering planned. 2 references |
| A.8.24 | Use of cryptography | Implemented | TLS 1.2+ in transit on public-network connections. The only exception is internal: the first hop of screen recording (DVR) and activity data from the RDS server to the farm hub uses plain HTTP without TLS at the application layer and is carried only inside an encrypted server-to-server WireGuard tunnel. At rest: platform data is stored in the managed database hosted by Supabase, whose at-rest encryption is provided by the hosting provider as part of its managed service and is not configured by Klyrix; some integration credentials, for example object-storage access keys and cloud-provider API credentials, are stored in Supabase Vault, which keeps them encrypted. Secret rotation log + Ed25519 federated auth (HR D-027/D-039). 2 references |
| A.8.25 | Secure development life cycle | Partial | Local pre-push gate on every push (backoffice + worker unit tests, type checks, security lints, npm audit baseline, lockfile validation) + weekly local OWASP ZAP baseline. No branch protection or enforced second-person review on main (single maintainer); the gate runs locally on the maintainer's machine, not server-side. 2 references |
| A.8.26 | Application security requirements | Implemented | Security headers, CSRF, rate limit, scope-based auth as middleware concerns. 2 references |
| A.8.27 | Secure system architecture and engineering principles | Implemented | Defense-in-depth: middleware + RLS + scope-auth + audit + monitoring. 2 references |
| A.8.28 | Secure coding | Implemented | ESLint baseline + TypeScript strict + Dependabot + npm audit + pre-push gate. 2 references |
| A.8.29 | Security testing in development and acceptance | Partial | Vitest suites (backoffice + worker) run on every push via the local pre-push gate + weekly local OWASP ZAP baseline + manual smoke endpoints. No SAST pipeline yet (SoA treatment plan TP-06). 3 references |
| A.8.30 | Outsourced development | N/A | No outsourced development; all code is authored in-house by the single maintainer. Third-party code enters as npm dependencies (Dependabot updates are merged locally through the pre-push gate) and as vendored browser libraries in backoffice/public/topo (d3, topojson-client). |
| A.8.31 | Separation of development, test and production environments | Implemented | Production = main branch, auto-deployed by Vercel; development and automated tests run locally before every push (pre-push gate). No PR or preview-deployment flow (single maintainer). 3 references |
| A.8.32 | Change management | Partial | Changes are tested and deployed through the local pre-push gate and tracked in git history, but approval is not independent: single maintainer, no enforced second-person review on main. 2 references |
| A.8.33 | Test information | Partial | Test fixtures use synthetic data; no production PII in test suites. Test suites use synthetic fixtures; masking for production-derived test data is not in place (planned, SoA A.8.33). 2 references |
| A.8.34 | Protection of information systems during audit testing | Implemented | Read-only audit access patterns documented; production audit changes go through change mgmt. 1 reference |
SOC 2 Trust Services Criteria
Security (Common Criteria) — 33 criteria
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| CC1.1 | COSO Principle 1: Demonstrates commitment to integrity and ethical values | Implemented | 1 reference |
| CC1.2 | COSO Principle 2: Exercises oversight responsibility | Implemented | 2 references |
| CC1.3 | COSO Principle 3: Establishes structure, authority, and responsibility | Implemented | 1 reference |
| CC1.4 | COSO Principle 4: Demonstrates commitment to competence | Partial | Training log table and operator entry page are in place; the annual security awareness programme has not been launched yet (TP-05, target 2026-Q4); same gap as ISO A.6.3. 2 references |
| CC1.5 | COSO Principle 5: Enforces accountability | Implemented | 2 references |
| CC2.1 | COSO Principle 13: Obtains and uses relevant, quality information | Implemented | 2 references |
| CC2.2 | COSO Principle 14: Communicates internally | Implemented | Telegram channels + email + status.klyrix.com. 1 reference |
| CC2.3 | COSO Principle 15: Communicates externally | Implemented | 3 references |
| CC3.1 | COSO Principle 6: Specifies suitable objectives | Implemented | 1 reference |
| CC3.2 | COSO Principle 7: Identifies and analyzes risks | Implemented | 1 reference |
| CC3.3 | COSO Principle 8: Assesses fraud risk | Implemented | 2 references |
| CC3.4 | COSO Principle 9: Identifies and assesses significant change | Implemented | 1 reference |
| CC4.1 | COSO Principle 16: Conducts ongoing and/or separate evaluations | Implemented | 2 references |
| CC4.2 | COSO Principle 17: Evaluates and communicates deficiencies | Implemented | 1 reference |
| CC5.1 | COSO Principle 10: Selects and develops control activities | Implemented | 1 reference |
| CC5.2 | COSO Principle 11: Selects and develops general controls over technology | Implemented | 2 references |
| CC5.3 | COSO Principle 12: Deploys through policies and procedures | Implemented | 1 reference |
| CC6.1 | Implements logical access controls | Implemented | 3 references |
| CC6.2 | Registers, authorizes, and modifies new internal/external users | Implemented | 2 references |
| CC6.3 | Authorizes, modifies, removes access based on role | Implemented | 2 references |
| CC6.4 | Restricts physical access | Partial | Data-centre physical access is inherited from sub-processors (see ISO A.7.1/A.7.2). Physical access controls of the Klyrix office (in ISMS scope) are not yet documented or evidenced (TP-11). 2 references |
| CC6.5 | Discontinues logical/physical access upon termination | Implemented | 2 references |
| CC6.6 | Implements network-level access controls | Implemented | 2 references |
| CC6.7 | Restricts data transmission/movement | Implemented | TLS 1.2+ in transit on public-network connections. The only exception is internal: the first hop of screen recording (DVR) and activity data from the RDS server to the farm hub uses plain HTTP without TLS at the application layer and is carried only inside an encrypted server-to-server WireGuard tunnel. SCCs for cross-border transfers; DPA with sub-processors. 1 reference |
| CC6.8 | Prevents/detects malicious software | Partial | Windows Defender enforced; Linux EDR via kill-switch when infra ready. 2 references |
| CC7.1 | Detects unauthorized changes via security configuration baselines | Implemented | 2 references |
| CC7.2 | Monitors system components for anomalies and incidents | Implemented | 2 references |
| CC7.3 | Evaluates security events for response | Implemented | 1 reference |
| CC7.4 | Responds to identified security incidents | Implemented | 2 references |
| CC7.5 | Recovers from identified incidents | Implemented | 1 reference |
| CC8.1 | Authorizes, designs, develops, configures, tests, approves, and implements changes | Partial | Changes are authorized, tested and deployed through the local pre-push gate and git history, but approval is not independent: single maintainer, no enforced second-person review on main. 2 references |
| CC9.1 | Identifies, selects, and develops risk mitigation activities | Implemented | 1 reference |
| CC9.2 | Assesses and manages risks associated with vendors and business partners | Implemented | 1 reference |
Availability — 3 criteria
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| A1.1 | Maintains, monitors, and evaluates current processing capacity | Implemented | 2 references |
| A1.2 | Authorizes, designs, develops, implements environmental protections | Implemented | 2 references |
| A1.3 | Tests recovery plan procedures | Implemented | 2 references |
Confidentiality — 2 criteria
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| C1.1 | Identifies and maintains confidential information | Implemented | Implemented while ISO 27001 A.5.12 stays Partial on the same evidence (recorded decision): C1.1 requires confidential information to be identified and maintained, which the processing inventory (ROPA) and the retention policy do; it does not require a sensitivity-level classification scheme, the missing piece that keeps A.5.12 Partial. 2 references |
| C1.2 | Disposes of confidential information | Implemented | 1 reference |
Processing Integrity — 5 criteria
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| PI1.1 | Obtains/generates relevant, quality information regarding objectives | Partial | Audit logs cover most internal processing; customer-facing data integrity is RDS host scope. 1 reference |
| PI1.2 | Implements policies/procedures over system inputs | Implemented | 2 references |
| PI1.3 | Implements policies/procedures over system processing | Implemented | 1 reference |
| PI1.4 | Implements policies/procedures to make output complete, accurate, timely | Implemented | 1 reference |
| PI1.5 | Implements policies/procedures to store inputs/items in process completely, accurately | Implemented | 1 reference |
Privacy — 8 criteria
| ID | Name | Status | Evidence / Notes |
|---|---|---|---|
| P1.1 | Notice and communication of objectives | Implemented | 3 references |
| P2.1 | Choice and consent | Implemented | 1 reference |
| P3.1 | Collection | Implemented | 1 reference |
| P4.1 | Use, retention, and disposal | Implemented | 1 reference |
| P5.1 | Access | Implemented | 2 references |
| P6.1 | Disclosure and notification | Implemented | 1 reference |
| P7.1 | Quality | Implemented | 1 reference |
| P8.1 | Monitoring and enforcement | Implemented | 1 reference |
Need deeper evidence?
Enterprise prospects and auditors can request the full ISMS pack (policies, risk register, Statement of Applicability) from security@klyrix.com under NDA. Sub-processor SOC 2 reports and pentest results are available on the same channel.
Coverage data computed at build time.