Security & Zero-Access Policy

01. Introduction & Corporate Identity

This Security & Zero-Access Policy ("Policy") sets out the technical, operational, and procedural security measures implemented by KHODSHIMA SUMN ASSIST LTD ("Company", "we", "us", or "our"), a private limited company incorporated in England and Wales under company registration number 17435961, with its registered office at 128 City Road, London, United Kingdom, EC1V 2NX.

This Policy describes the Company's zero-access architecture — a security model designed to ensure that the Company cannot retain, recover, or misuse access to client infrastructure beyond the scope of a commissioned service engagement. The Policy is issued in accordance with the UK Data Protection Act 2018, UK GDPR, the Computer Misuse Act 1990, and industry best practices including ISO/IEC 27001 control objectives and NIST Cybersecurity Framework principles.

02. Zero-Access Architecture Principles

The Company operates on a zero-access model — meaning the Company does not maintain permanent access to any client infrastructure. The following principles govern all service engagements:

• No Permanent Credentials: The Company does not store, retain, or persist any SSH private keys, root passwords, API tokens, or other authentication credentials for client systems beyond the active maintenance window;
• Ephemeral Access: All server access is granted through temporary, purpose-specific credentials that are revoked immediately upon completion of the engagement;
• Client-Controlled Revocation: The Client retains full control over credential revocation. The Company cannot re-establish access without the Client's explicit authorisation;
• No Backdoors: The Company does not install hidden access mechanisms, persistent SSH keys, cron-based reverse shells, or any other covert access channels on client systems;
• No Credential Databases: The Company does not maintain a database, password vault, or any storage system containing client access credentials;
• Need-to-Know: Access to client systems is restricted to the specific engineer performing the work, for the specific duration required, and for the specific scope commissioned.

03. Ephemeral SSH Access Protocol

For Turnkey Installation services, the Company requires temporary SSH access to the Client's designated Linux server(s). The following protocol is mandatory:

Ed25519 Key Specification: All SSH keys are Ed25519 (Curve25519 elliptic curve), not RSA. Ed25519 provides superior security with smaller key sizes, faster signature verification, and resistance to side-channel attacks. Keys are generated using OpenSSH 8.0+ with default parameters.

04. Encryption & Data Protection

The Company applies encryption at rest and in transit across all systems:

• In Transit: All SSH connections use strong cipher suites (ChaCha20-Poly1305 or AES-256-GCM). TLS 1.2+ is enforced for all web traffic, API calls, and email communication. Insecure protocols (TLS 1.0, TLS 1.1, SSLv3) are disabled;
• At Rest: Diagnostic data, audit reports, and any temporary artifacts collected during service delivery are stored in AES-256 encrypted volumes. Encryption keys are managed through hardware-backed key stores where available;
• Key Management: Encryption keys are rotated periodically. Access to decryption keys is restricted to authorised personnel on a need-to-know basis;
• Payment Data: The Company does not store, process, or transmit cardholder data. All payment operations are handled by Stripe and Airwallex within their PCI-DSS Level 1 certified environments;
• Client Data Minimisation: The Company collects only the minimum data necessary to perform the commissioned service. Diagnostic output is scoped to the specific hardening task and does not include unrelated system data;
• Secure Deletion: When data is no longer required (after the Warranty Period), it is securely deleted using cryptographic erasure or multi-pass overwrite, not simple file deletion.

05. Data Retention & Deletion Schedule

06. Access Control & Internal Security

The Company maintains strict access controls for its own internal systems:

• Principle of Least Privilege: Personnel are granted the minimum access level required to perform their assigned tasks. Access rights are reviewed quarterly;
• Multi-Factor Authentication (MFA): All Company internal systems, code repositories, cloud consoles, and administrative interfaces require MFA using TOTP or hardware security keys (FIDO2/WebAuthn);
• Role-Based Access: Access to client data, source code, and infrastructure is governed by role-based access control (RBAC). Engineers access only the systems relevant to their active engagements;
• Session Management: Administrative sessions are time-limited and automatically terminated after inactivity. Concurrent sessions are restricted;
• Audit Logging: All access to internal systems, code repositories, and client data is logged with timestamp, user identity, and action performed. Logs are immutable and retained for 12 months;
• Network Security: Internal systems are protected by firewall rules, IP allowlisting for administrative access, and network segmentation between development, staging, and production environments;
• Device Security: All Company devices are encrypted (BitLocker / FileVault / LUKS), run up-to-date antivirus, and are enrolled in a mobile device management (MDM) system enabling remote wipe in case of loss or theft.

07. Incident Response & Breach Notification

The Company maintains an incident response plan for security events affecting Company or client systems:

1. Detection: Security events are detected through audit log monitoring, anomaly detection, client reports, and researcher vulnerability disclosures (see our Responsible Disclosure Policy);
2. Containment: Affected systems are isolated, compromised credentials are revoked, and access is terminated immediately;
3. Assessment: The scope and impact of the incident are assessed, including affected data categories, systems, and clients;
4. Notification:
   • Clients: Notified within 24 hours if their infrastructure or data is affected;
   • ICO: The Information Commissioner's Office is notified within 72 hours for personal data breaches under UK GDPR Art. 33;
   • Payment Providers: Stripe and Airwallex are notified if the incident affects payment integration or could compromise transaction security;
   • Law Enforcement: Action Fraud and UK police are notified for criminal incidents (unauthorised access, data theft, extortion).
5. Remediation: Vulnerabilities are patched, systems are restored from clean backups, and post-incident review is conducted;
6. Documentation: A post-incident report is prepared documenting timeline, root cause, impact, remediation, and preventive measures.

08. Prohibited Activities & Service Scope

The Company's security practices and zero-access architecture are designed exclusively for non-financial IT engineering services. The Company will not apply, configure, or adapt its security tooling for:

• Financial services, banking, or payment processing infrastructure;
• Cryptocurrency exchanges, wallets, or mining operations;
• Gambling, betting, or adult content platforms;
• Any FCA-regulated activity;
• Any infrastructure in sanctioned jurisdictions (Russian Federation, Belarus, Iran, North Korea, Syria, Cuba, occupied territories of Ukraine);
• Any activity prohibited under the Terms & Conditions.

09. Compliance & Audit Alignment

This Policy aligns with the following standards and regulatory frameworks:

• UK GDPR Art. 32: Security of processing — appropriate technical and organisational measures;
• ISO/IEC 27001: Access control (A.9), cryptography (A.10), operations security (A.12), and incident management (A.16) control objectives;
• NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, and Recover functions;
• CIS Controls v8: Access control management, secure configuration, audit log management, and data protection;
• PCI-DSS: SAQ-A scope — no cardholder data storage, payment processing fully delegated to Stripe and Airwallex;
• Computer Misuse Act 1990: All access to client systems is authorised, logged, and scoped to the commissioned engagement.

See our Compliance & Standards Overview for the full compliance framework.

10. Policy Amendments & Related Documents

This Policy is reviewed at least annually and updated as necessary to reflect changes in technology, threat landscape, or regulatory requirements. This Policy should be read in conjunction with:

• Privacy Policy — data protection and UK GDPR compliance;
• Terms & Conditions — service scope and prohibited activities;
• Purchase & Licensing Conditions — ephemeral server access in licensing context;
• Responsible Disclosure Policy — vulnerability reporting programme;
• Compliance & Standards Overview — comprehensive compliance framework.