Security & Data

1. About Hubflow and Our Security Approach

Hubflow is the trading name of Abdullah Anjum, an individual business operator based in Lahore, Pakistan. Hubflow is not an incorporated company.

Our services may involve websites, web and mobile applications, custom software, SaaS products, AI agents, chatbots, voice AI, CRM integrations, workflow automation, document processing and agreed maintenance.

The security requirements of a project should reflect the nature of the information involved, the systems used, the permissions required and the potential consequences of an error or incident.

Controls discussed on this page are not automatically included in every service. Their implementation, ownership and verification depend on the relevant systems, applicable obligations and documented scope.

2. Current Business Facts and Control Boundaries

The following distinguishes known operating arrangements from technical safeguards that depend on particular systems or project configurations.

• Operating location: Hubflow operates remotely from Lahore, Pakistan.
• Business structure: Hubflow is an individual-operated trading name rather than an incorporated company.
• Client systems: Client projects may involve accounts and business systems controlled by the client or third-party providers.
• Project arrangements: Agreed services, access, testing and maintenance responsibilities are defined through the applicable project documents.
• Technical safeguards: Access restrictions, MFA, storage protection, logging, monitoring, backups and related controls must be assessed for the systems in which they are used.

A capability offered by a provider does not establish that the capability is enabled for Hubflow or a client’s project. Actual configuration should be confirmed before making system-specific security commitments.

3. Data Roles and Responsibilities

Hubflow may process information for its own business activities, including enquiries, proposals, administration and client communications.

For these activities, the individual operator ordinarily determines the relevant purposes and means of processing, and may act as controller where that concept applies.

Client projects may involve customer communications, leads, invoices, documents, support tickets or other records belonging to a client.

When Hubflow processes that information under the client’s documented instructions, the client ordinarily controls the business purpose while Hubflow acts as processor or service provider, depending on the actual arrangement and applicable law.

Roles, processing instructions, permitted disclosures and relevant responsibilities should be documented in the project agreement or applicable data-processing agreement.

4. Data Minimisation and Approved Purposes

The information needed for a project depends on the approved workflow and its business purpose.

Before a workflow is implemented, the parties should identify:

• which information and fields are necessary for the task;
• the source of the information;
• the systems and providers that may receive it;
• authorised users and required access permissions;
• the intended retention and deletion arrangements;
• relevant security and compliance requirements; and
• situations requiring human review or escalation.

Sensitive, regulated or otherwise high-risk information should not be included in a workflow without an appropriate lawful purpose, permissions and agreed safeguards.

5. Access Permissions and Authentication

Access controls are determined by the relevant service, provider capabilities and agreed responsibilities.

Measures to evaluate for a project may include:

• individual user accounts rather than shared logins;
• role-based permissions and least-privilege access;
• multi-factor authentication where available and enabled;
• restricted administrative and integration permissions;
• separate development and production access where appropriate;
• periodic permission reviews;
• revocation of access when no longer required; and
• review of access after role, personnel or contractual changes.

MFA and individual account restrictions must be checked for the actual systems used. This page does not claim MFA is universally enabled across Hubflow accounts or connected client services.

Clients remain responsible for accounts, staff access and devices under their control. Hubflow is responsible for access under its own control, subject to the applicable agreement and legal duties.

6. Credentials, API Keys and Secrets

Projects may require credentials, API keys, tokens, service accounts or other access mechanisms to connect business systems.

The agreed setup should specify how access is granted, which permissions are needed, who manages the credentials and how access can be revoked.

Controls to consider include secure credential transfer, appropriate storage, restricted access, rotation and removal of credentials when no longer necessary.

Where supported, dedicated service accounts or restricted integration permissions may reduce the need to share ordinary user credentials.

Do not send passwords, API keys, recovery codes or other secrets through general contact forms or ordinary security-report emails.

No particular password manager, secrets vault or automated rotation system is represented here as universally deployed.

7. Transmission, Storage and Encryption

Website and system security should account for information during transmission and while stored.

HTTPS and transport encryption may protect relevant connections, but the use of HTTPS on a website does not establish that all connected applications, databases, exports, backups or internal transfers receive the same protections.

Storage and transmission arrangements depend on the selected hosting, application, database and integration providers.

Encryption at rest, encryption key management, storage access policies and other technical safeguards must be verified for the specific service before they are represented as implemented controls.

This page does not promise a universal storage location, encryption configuration or data-residency arrangement.

8. Infrastructure and Third-Party Providers

Hubflow projects may depend on external hosting, cloud, email, AI, messaging, CRM, accounting, analytics and automation platforms.

The providers selected for an engagement depend on the agreed solution and the client’s systems.

Relevant provider assessments may cover:

• the service and its intended processing purpose;
• the categories of data involved;
• access and authentication controls;
• available security documentation;
• processing and storage locations;
• applicable service terms and data-processing agreements;
• retention settings and available deletion methods; and
• material technical or operational dependencies.

Hubflow’s operation from Lahore, Pakistan may involve access to information from Pakistan. Additional countries may be involved depending on provider arrangements.

Where an international transfer requires particular safeguards, those requirements must be addressed for the actual processing arrangement.

9. AI Processing and Data Handling

AI services may involve sending approved information to external model or automation providers.

Depending on the workflow, this information may include prompts, customer messages, retrieved knowledge, document extracts or structured business records.

The project agreement should identify relevant providers, permitted purposes, data categories and any required restrictions.

AI providers can differ in their retention policies, model-training settings, processing locations and commercial terms.

The selected provider, product and configuration must therefore be evaluated rather than assuming that all AI services operate under identical conditions.

Client information should not be reused for unrelated purposes or model training without appropriate authority, applicable lawful grounds and any necessary agreement.

Hubflow does not make a blanket guarantee of zero retention, universal exclusion from model training or processing within one geographic region.

10. Human Oversight and Restricted Actions

AI employees and automation workflows are intended to operate within approved business rules and permissions.

The client and Hubflow should determine which tasks can proceed automatically and which require review, approval or escalation.

Examples of activities requiring particular attention may include:

• complaints, disputes and legal threats;
• refunds, payment exceptions and significant commercial commitments;
• identity verification and sensitive account changes;
• regulated professional advice;
• employment, credit, healthcare or safety decisions;
• access to highly sensitive information; and
• requests beyond the agreed system permissions.

Clients are responsible for identifying authorised actions, review requirements, escalation contacts and appropriate stopping conditions.

A workflow can enforce only the controls that are correctly specified, configured and maintained.

11. Development and Testing

Testing requirements are determined by the agreed project scope, the type of system and its risks.

Relevant testing may include routine transactions, missing information, unexpected inputs, failed integrations, access restrictions and human escalation scenarios.

The project agreement should identify any required acceptance criteria, client review obligations and testing deliverables.

Security testing, independent penetration testing, automated vulnerability scanning or specialised compliance testing are not automatically included in every engagement.

Those activities must be expressly scoped where required.

Clients should review relevant business rules, permissions, messages, knowledge sources and acceptance results before approving deployment.

12. Change Control and Deployment

Changes to AI prompts, models, permissions, data sources, integrations or automated actions may affect system behaviour, security and reliability.

For relevant changes, a project may require review, testing, documentation and client approval before production deployment.

Material changes outside the agreed scope may require a revised specification, schedule or commercial agreement.

Emergency measures may be necessary to contain security or operational risks. Any related notification, documentation and approval duties are governed by the applicable agreement and legal requirements.

A universal deployment approval system is not represented here as operating across all projects.

13. Logs and Activity Records

Technical logs, application records, workflow histories and error information may be available through the selected systems.

Where logging is supported and included in the agreed configuration, it may assist with troubleshooting, reviewing workflow activity, investigating incidents and diagnosing failures.

The scope and retention of logs should reflect operational needs, privacy considerations and applicable obligations.

Logging arrangements should avoid unnecessary collection of confidential or sensitive information.

Not every external provider supplies the same level of technical or security activity records.

14. Monitoring and Maintenance

Monitoring and ongoing technical maintenance are provided where included in the relevant service or management agreement.

Depending on the selected systems and agreed services, monitoring may involve error notifications, integration failures, workflow histories, system status information or other available indicators.

The contract should identify any monitoring coverage, responsibilities, reporting arrangements and response commitments.

This page does not promise continuous monitoring, immediate detection of incidents or 24-hour support.

Monitoring does not guarantee that every malfunction or security event will be detected before it affects a service.

15. Backups and Recovery

Backup and recovery arrangements depend on the hosting environment, selected providers and agreed project scope.

Where backups are required, the parties should identify:

• which systems and data require backup;
• the party responsible for creating backups;
• available backup schedules and retention;
• storage and access arrangements;
• whether restoration testing is included; and
• any agreed recovery objectives or procedures.

A provider offering a backup feature does not establish that it is enabled, complete, tested or recoverable for a particular deployment.

Hubflow does not promise universal backup frequency, tested recovery capability or guaranteed recovery times through this page.

Clients should maintain appropriate continuity arrangements for their own business-critical systems and information.

16. Retention and Deletion

Retention requirements vary according to the category of information, its purpose, the selected provider and applicable legal or contractual duties.

Project-specific arrangements should address retention of relevant source data, AI prompts and outputs, activity logs, documents, exports and backups.

Where deletion is required, the responsible party and available deletion procedures should be defined in the applicable arrangements.

Data removed from active systems may remain in backups for a period determined by the actual backup configuration.

Backup expiry, residual access and treatment of restored backup information should be addressed where relevant.

This overview does not establish a universal retention period, immediate deletion guarantee or fixed backup expiry cycle.

17. Incident Assessment and Reporting

A suspected security or privacy incident may require assessment, containment, investigation, documentation and appropriate notification.

The applicable legal duties and project arrangements determine which parties must be informed and which response obligations apply.

Where Hubflow becomes aware of an incident affecting information processed for a client, notification and cooperation will follow the relevant agreement and applicable law, including any mandatory notification requirements.

Contractual incident contacts, escalation methods and required notification periods should be established for relevant engagements.

This page does not promise a fixed acknowledgement time, resolution deadline, staffed security operations centre or uninterrupted emergency support.

Suspected issues can be reported to hello@hubflowhq.com .

18. Responsible Vulnerability Reporting

If you suspect a vulnerability affecting a Hubflow website or service, please report it using the security contact below.

A useful report may include:

• the affected domain, page or service;
• an approximate time when the issue occurred;
• a brief description of the observed behaviour;
• safe reproduction steps that do not expose third-party information; and
• a contact method for any necessary follow-up.

Do not include passwords, API keys, access tokens, recovery codes, private customer records or unnecessary sensitive data in ordinary email.

Please avoid destructive testing, disruption of services, unauthorised access or downloading information belonging to other people.

Request written authorisation before performing intrusive security testing. This reporting channel is not a bug-bounty programme and does not promise compensation.

Nothing in this section restricts lawful reporting to competent authorities or other protected disclosures.

19. Offboarding and Access Revocation

The end of a project may require actions concerning accounts, credentials, connected services, client information and technical handover.

Relevant offboarding arrangements should identify responsibility for:

• revoking project-related accounts and permissions;
• disabling or rotating integration credentials;
• transferring agreed deliverables and documentation;
• disconnecting external applications or services;
• returning or deleting client information;
• handling retained records and backups; and
• arranging any agreed migration or transition assistance.

Hubflow can revoke access within its control. Clients and third-party providers may need to revoke permissions in systems they control.

Deliverable handover, transition assistance, retention and deletion follow the applicable project agreement, processing arrangements and legal obligations.

20. Client Security Responsibilities

Clients remain responsible for decisions, accounts, business systems and information under their control.

Relevant responsibilities may include:

• providing accurate information about risks and data categories;
• approving permitted workflow actions, users and integrations;
• securing employee accounts, devices and credentials;
• enabling appropriate authentication controls;
• maintaining lawful processing instructions and privacy notices;
• reviewing escalations, exceptions and important outputs;
• protecting original business records and source systems;
• informing Hubflow of relevant permission, personnel or security changes; and
• maintaining appropriate continuity and recovery arrangements.

The allocation of responsibilities for a specific engagement is determined by the project documents and applicable law.

21. Certifications and Assurance

This page does not represent Hubflow as independently certified under ISO 27001, SOC 2, Cyber Essentials or another security assurance framework.

Any future certification or assurance statement must be supported by appropriate evidence identifying its scope, applicable entity and validity.

A hosting, AI or software provider may hold certifications or independent assurance reports.

Those qualifications relate to the provider’s own assessed services and do not automatically certify Hubflow, a client’s configuration or the complete workflow.

Contractual security responsibilities remain subject to the relevant agreement and applicable law.

22. Security Information for Clients

Depending on the nature and scope of an engagement, supporting security documentation may be discussed or agreed.

Possible documentation includes:

• a summary of relevant data flows;
• identified service providers and integration dependencies;
• agreed access roles and permissions;
• project-specific security requirements;
• a data-processing agreement where required;
• agreed retention and deletion arrangements;
• incident contacts and procedures; and
• responses to proportionate security questions.

The availability and contents of such documentation depend on the actual service, relevant systems and contractual arrangements.

Confidential information about internal systems may be subject to appropriate disclosure restrictions.

23. Related Policies and Agreements

For related information, please review:

• Privacy Policy — information about personal data processing and applicable privacy rights.
• Cookie Policy — information about cookies and similar website technologies.
• Terms & Conditions — website use and service engagement terms.

A client’s signed proposal, statement of work, security schedule or data-processing agreement may contain additional obligations specific to that engagement.

This public overview does not override mandatory legal duties or the agreed order of contractual documents.