Security Policy

Security Policy

This Security Policy explains the public-facing security framework used by Quantum Intelligence Hub Ltd (“QIH”, “we”, “us” or “our”) for QIHHUB.COM and related QIH-operated services, including websites, hosting and automation environments, AI Digital Reception services, customer portals, communication channels and supporting infrastructure.

This policy is a high-level operational summary. It does not disclose confidential system architecture, credentials, internal control records, detection rules or other information that could weaken security.

1. Scope and Security Objectives

Our security programme is intended to support:

• confidentiality, integrity and availability of systems and information;
• resilient and lawful service delivery;
• prevention and detection of unauthorised access, fraud, abuse and disruption;
• appropriate protection of personal information and customer-controlled data;
• timely containment, investigation and recovery following security events;
• continuous improvement based on risk, operational experience and evolving threats.

2. Governance and Risk Management

Security controls are selected and reviewed using a risk-based approach. Depending on the service and risk, QIH may document asset ownership, access requirements, supplier dependencies, data flows, recovery priorities and incident-response responsibilities.

Security is reviewed throughout the lifecycle of a service, including design, implementation, operation, material change and termination. Controls may be adjusted where a risk assessment, legal requirement, supplier change, security event or material technical development makes this appropriate.

3. Shared Responsibility

Security is shared between QIH, the customer and relevant infrastructure or channel providers. QIH is responsible for security measures within systems and processes under its control. Customers remain responsible for their own users, devices, networks, accounts, content, instructions, legal permissions and third-party services they select or administer.

Each party is responsible for loss, misuse or non-compliance caused by its own acts, omissions, credentials, personnel or systems, subject to the applicable agreement and mandatory law.

4. Identity and Access Management

QIH may apply controls such as:

• role-based and least-privilege access;
• unique user accounts and appropriate authentication;
• multi-factor authentication where supported and proportionate;
• administrative separation and restricted privileged access;
• periodic access review and prompt access removal following role change or departure;
• monitoring of material administrative actions where technically available.

5. Credentials, API Keys and Secrets

Passwords, API secret keys, webhook signing secrets, access tokens and recovery codes must be treated as confidential. QIH and customers should:

• keep public and secret credentials in their correct fields and never expose secret values in public pages, email, chat or screenshots;
• separate test and live credentials and environments;
• verify expected key types and prefixes, for example publishable keys, secret keys and webhook signing secrets;
• use secure storage and restricted access rather than embedding secrets in source code;
• rotate or revoke credentials promptly after suspected exposure, personnel changes or supplier guidance;
• avoid reusing credentials across unrelated systems.

QIH may reject incorrectly formatted credentials or temporarily disable an integration where necessary to protect customers or systems.

6. Infrastructure, Platform and Network Security

Depending on the service architecture and provider capabilities, QIH may use secure configuration, transport encryption, firewalls, traffic filtering, environment separation, protected administrative interfaces, security updates, availability controls and cloud-provider safeguards.

Infrastructure may be hosted or processed through independent cloud, hosting, telecommunications and software providers. Their controls and availability form part of the overall service dependency chain.

7. Application and Development Security

For QIH-developed or configured systems, security considerations may include input validation, authentication and authorisation checks, secure error handling, dependency review, change control, separation of test and production data, logging of material events and testing proportionate to the change and risk.

No publication of this policy represents a guarantee that software is free from defects or vulnerabilities. Identified issues are assessed and addressed according to severity, exploitability, customer impact and available remediation.

8. AI Digital Reception and Communication Channels

AI Digital Reception services may connect with telephone, web chat, email, WhatsApp, social media, forms, calendars, CRM systems and other customer-selected channels. Security depends partly on the configuration and protection of each connected provider account.

• Customers must authorise connections and maintain lawful access to connected accounts.
• Call audio, transcripts, messages and contact details must only be collected or retained where lawful, necessary and configured for the service.
• AI responses must not be relied upon for emergency services, medical diagnosis, legal representation or other high-risk decisions unless expressly agreed and appropriately supervised.
• Passwords, one-time passcodes, full payment-card data and unrelated sensitive information should not be requested through AI conversations.
• Payments should be directed to an approved hosted checkout or payment-provider environment.

9. Data Security and Encryption

QIH seeks to minimise personal information and restrict access according to purpose. Encryption in transit is used where supported and appropriate. Encryption or equivalent provider safeguards for stored information may be used according to the service, risk and platform capability.

Encryption reduces risk but does not eliminate it. Customers must also secure endpoints, exports, downloaded files, local backups and information copied into their own systems.

10. Logging, Monitoring and Abuse Detection

QIH and its providers may record security, access, authentication, integration, system-performance and error events for security, fraud prevention, troubleshooting, service continuity and legal compliance. Monitoring may detect unusual access, repeated failures, malicious automation, spam, misuse or infrastructure instability.

Monitoring is not continuous human surveillance and cannot detect every event. Logs are restricted and retained only for a proportionate operational or legal period.

11. Vulnerability and Patch Management

QIH assesses relevant vulnerabilities and security updates according to risk. Remediation priority may consider severity, credible exploitation, internet exposure, information sensitivity, operational impact, supplier availability and safe deployment requirements.

Customers must keep their own devices, browsers, plugins, integrations and connected systems supported and reasonably up to date.

12. Suppliers and Subprocessors

QIH may use hosting, cloud, payment, telephony, messaging, analytics, automation and support providers. Supplier selection and review may consider service criticality, security information, contractual safeguards, data location, access scope, resilience and incident procedures.

A supplier relationship does not transfer responsibility for that supplier’s independent acts to QIH beyond the allocation required by the applicable agreement and law.

13. Backups, Recovery and Continuity

Where included in the relevant service, QIH or its providers may maintain backups, redundancy, recovery procedures and continuity measures proportionate to service criticality. Backup frequency, retention and restoration capability differ by service and must not be assumed unless documented.

Customers remain responsible for independent copies of information they are required to retain and for a practical continuity plan where interruption could materially affect their operations.

14. Security Incident Management

QIH assesses suspected incidents, seeks to contain confirmed threats, preserves relevant evidence where appropriate, coordinates with affected providers and restores service according to priority. Where QIH becomes aware of a personal-data breach or significant service-security risk requiring notice, communication will be made to the relevant customer or authority in accordance with applicable law and contractual roles.

Customers must promptly report suspected compromise, revoke exposed credentials where possible, preserve relevant evidence and cooperate with reasonable containment steps.

15. Customer Security Responsibilities

• provide accurate authorised-user information and remove obsolete access;
• use strong authentication and multi-factor authentication where available;
• protect devices, networks, inboxes, phone accounts and connected platforms;
• grant integrations only the permissions reasonably required;
• configure lawful recording notices, consent choices and retention settings;
• avoid uploading unnecessary sensitive or special-category information;
• review AI instructions, business knowledge, automated actions and customer-facing outputs;
• notify QIH promptly of suspected misuse, credential exposure or security incidents.

16. Security Testing and Responsible Disclosure

Security testing must not be performed against QIH systems without prior written authorisation. Researchers who believe they have identified a vulnerability should avoid privacy violations, data access, persistence, disruption, extortion or public disclosure before QIH has had a reasonable opportunity to investigate.

See our Security Disclosure Policy or contact security@qihhub.com.

17. Enforcement, Suspension and Accountability

QIH may restrict an integration, credential, feature or account where reasonably necessary to contain a threat, investigate misuse, protect affected persons, comply with law or preserve infrastructure. Where practicable, the scope and duration of a restriction will be limited to what is reasonably necessary.

Responsibility for an incident rests with the party whose breach, negligence, unlawful instruction, insecure configuration, personnel or controlled system caused it, subject to causation, contributory fault, the governing agreement and mandatory law.

18. Limitations and Policy Updates

This policy does not create an absolute security warranty, guaranteed uptime commitment or certification. Service-specific security obligations, service levels, data-processing terms and liability provisions are governed by the applicable contract. Nothing in this policy excludes liability that cannot lawfully be excluded.

QIH may update this policy to reflect changes in services, risks, technology, law or operational controls. Material changes will be published with an updated date.

19. Related Policies

• Security Disclosure Policy
• Privacy Policy
• Data Protection Policy
• Acceptable Use Policy
• AI & Automated Systems Policy
• Terms & Conditions
• QIH HUB AI Master Service Agreement

20. Contact

For security reports or operational security enquiries:

QUANTUM INTELLIGENCE HUB LTD
71–75 Shelton Street
Covent Garden
London, WC2H 9JQ
United Kingdom

Security: security@qihhub.com
Privacy: privacy@qihhub.com
Legal: legal@qihhub.com
General: info@qihhub.com