Security & Data

1. Our Security Approach

We use a risk-based approach intended to protect the confidentiality, integrity and availability of information. Controls are selected according to the workflow, information involved, platforms used, access required and potential impact of failure.

We aim to:

• collect and access only information needed for the agreed purpose;
• restrict access to authorised people and systems;
• use reputable providers appropriate to the service;
• test workflows before production use;
• keep human review for sensitive or high-risk situations;
• monitor supported production workflows for technical issues; and
• respond to suspected security incidents through a documented process.

2. Data Roles

For information collected through our own website, sales and administration, Hubflow normally acts as a data controller.

For personal information processed inside a client’s AI employee or automation workflow, the client normally acts as controller and Hubflow normally acts as processor or service provider. The precise roles depend on the service and applicable law and should be recorded in the contract or data-processing agreement.

Clients remain responsible for deciding why their data is processed, ensuring an appropriate lawful basis, providing required notices and defining lawful business rules. Hubflow processes client data according to agreed instructions and applicable contractual obligations.

3. Data Minimisation and Purpose Limitation

We design workflows to use the minimum information reasonably required for the approved task. Before implementation, we seek to identify:

• which data fields are genuinely required;
• where the information comes from;
• which systems receive it;
• who needs access;
• how long it should be retained; and
• which situations require human review.

Clients should avoid providing special-category, regulated or highly sensitive information unless it is necessary, lawful and expressly included in the agreed design.

4. Access Controls

Depending on the selected systems and service scope, access safeguards may include:

• individual user accounts rather than shared credentials;
• multi-factor authentication where supported;
• least-privilege permissions;
• role-based access controls;
• credential rotation and revocation;
• separate development or test access where appropriate; and
• review of access when a role or engagement changes.

Clients are responsible for securing their own accounts, devices, users and credentials and for promptly removing access that is no longer required.

5. Encryption and Transmission

We use encrypted connections for website and service communications where supported by the relevant platform. Approved cloud providers may also provide encryption at rest and other platform safeguards.

The exact encryption, key-management and storage controls depend on the providers selected for a project. They should be confirmed during technical scoping rather than assumed from this public page.

6. Infrastructure and Service Providers

Hubflow may use third-party hosting, cloud, AI, automation, email, messaging, CRM, help-desk, accounting and monitoring providers to deliver an agreed service.

We consider the provider’s role, access, security information, contractual terms, data location and suitability for the workflow. The providers used for a specific client may be listed in the proposal, data-processing agreement or subprocessor information.

No provider should be represented as certified or compliant on Hubflow’s behalf unless that claim has been verified and applies to the relevant service.

7. AI Data Handling

AI workflows are configured for defined tasks and approved data sources. Depending on the project, a model provider may process prompts, retrieved knowledge, customer messages or structured fields needed to produce an output.

We seek to limit the information sent to an AI provider to what the workflow requires. Provider settings, retention options and contractual protections are considered during implementation.

Hubflow does not use client data to train its own general-purpose AI models. Whether a third-party provider may retain or use information is governed by the selected product, account settings and contract. This should be verified for every production implementation.

8. Human Oversight and Restricted Actions

AI employees are intended to operate within approved rules. Human review should be retained for sensitive, unusual or high-impact situations, including:

• complaints, disputes and legal threats;
• refunds, payment exceptions and material commercial commitments;
• sensitive account or identity changes;
• regulated professional advice;
• employment, credit, healthcare, legal or safety decisions; and
• any request outside the approved workflow.

Clients define permitted actions, stopping conditions, escalation contacts and review requirements. A workflow can only enforce controls that are properly specified, configured and maintained.

9. Development, Testing and Change Control

Before launch, we aim to test routine, unclear, failed and escalation scenarios relevant to the agreed scope. The client reviews and approves business rules, messages, knowledge, permissions and launch readiness.

Material changes to prompts, data sources, permissions, integrations or automated actions should be tested and approved before production use. Emergency changes may be made to contain a security or operational risk and documented afterwards.

10. Logging and Monitoring

Where supported and included, we may use technical logs, workflow histories, error alerts and activity records to troubleshoot, monitor performance and investigate security events.

Logging should be proportionate to the risk and should avoid retaining unnecessary sensitive information. Monitoring does not guarantee that every error or malicious activity will be detected immediately.

11. Retention and Deletion

Retention depends on the data role, service, provider and client agreement. Client workflow data is retained only for the agreed service period and deletion or return window, subject to lawful backup, security and record-keeping requirements.

At the end of an engagement, access should be revoked and client information returned or deleted according to the contract and data-processing agreement. Some residual information may remain temporarily in protected backups until overwritten under the applicable backup cycle.

12. Backups and Resilience

Where relevant to the service, we rely on backup, recovery and availability features provided by selected platforms and may configure additional safeguards where included in scope.

Clients should maintain appropriate backups and continuity plans for their source systems and business-critical data. An AI employee or automation workflow should not be the only copy of an important business record.

13. Incident Response

We maintain a process intended to identify, contain, investigate and document suspected security incidents affecting systems under our control.

Where an incident affects client information, we will notify the relevant client without undue delay after becoming aware, in accordance with the contract and applicable law, and provide information reasonably available to support the client’s assessment and response.

Clients should report suspected issues promptly to [SECURITY EMAIL] and include the affected service, approximate time and a safe description of the concern. Do not send passwords, secret keys or unnecessary sensitive data by ordinary email.

14. Vulnerability Reporting

If you believe you have found a security vulnerability affecting Hubflow, contact [SECURITY EMAIL] before publicly disclosing it.

Please:

• describe the issue and affected URL or service;
• provide safe reproduction steps;
• avoid accessing, changing or downloading data that is not yours;
• avoid disrupting services or using destructive testing; and
• allow reasonable time for investigation and remediation.

This section does not create a bug-bounty programme or promise payment.

15. Client Security Responsibilities

Security is shared. Clients are expected to:

• use strong authentication and multi-factor authentication where available;
• limit permissions to what the workflow requires;
• provide accurate data-classification and risk information;
• keep devices, accounts and source systems secure;
• approve users, actions, rules and escalation paths;
• review reports and human escalations promptly;
• notify Hubflow of account, personnel or risk changes; and
• comply with applicable privacy, communications and sector rules.

16. Certifications and Independent Assurance

Hubflow does not claim ISO 27001, SOC 2, Cyber Essentials or another certification unless the certification is current, independently verifiable and expressly listed here.

Current Hubflow certifications: [NONE / LIST VERIFIED CERTIFICATIONS AND LINKS]

Third-party provider certifications belong to those providers and do not automatically certify Hubflow or the complete client workflow.

17. Security Documentation for Clients

Depending on engagement size and risk, we may provide appropriate supporting information such as:

• a data-flow summary;
• a list of relevant service providers;
• agreed retention and deletion terms;
• a data-processing agreement;
• responses to a proportionate security questionnaire; and
• incident-notification and contact procedures.

Requests may be subject to confidentiality requirements and reasonable scope limits.