Legal
Acceptable Use Policy
Contents
- 1. Purpose of this Policy
- 2. Who Must Comply
- 3. Relationship With the Terms of Service
- 4. Core Acceptable-Use Rule
- 5. Legitimate Organisational Use
- 6. The Customer Must Establish Its Own Authority
- 7. Purpose Declarations
- 8. No Personal Curiosity Searches
- 9. No Searches for Friends, Family or Colleagues Without Legitimate Authority
- 10. No Stalking or Harassment
- 11. Domestic Abuse and Coercive Control
- 12. No Doxxing
- 13. No Identity Theft
- 14. No Fraud or False Representation
- 15. No Unlawful Obtaining or Disclosure of Personal Data
- 16. No Unauthorised Surveillance
- 17. Vulnerable Individuals
- 18. Children
- 19. Discrimination
- 20. Significant Decisions
- 21. Automated Decisions
- 22. Facts, Matches, Associations and Inferences
- 23. Address Associations
- 24. Historical Information
- 25. Accuracy
- 26. Direct Marketing
- 27. Suppression and Objection Rights
- 28. No Resale Unless Expressly Authorised
- 29. Permitted Professional Disclosure
- 30. No Database Reconstruction
- 31. No Speculative Bulk Collection
- 32. Data Minimisation
- 33. Retention
- 34. Exported Data
- 35. No Public Publication
- 36. AI and Machine-Learning Use
- 37. No Scraping of the Portal
- 38. API Automation Is Permitted Subject to Controls
- 39. API Credentials
- 40. Credential Ownership
- 41. Compromised Credentials
- 42. No Credential Sharing Between Organisations
- 43. User Accounts
- 44. No Cross-Tenant Access
- 45. Security Testing
- 46. No Unauthorised Access
- 47. Rate Limits
- 48. Usage and Spending Limits
- 49. No Service Interference
- 50. Malware and Harmful Content
- 51. Reverse Engineering
- 52. Supplier Identity and Confidential Information
- 53. Confidential Information
- 54. Sandbox Environment
- 55. Customer Applications
- 56. Do Not Remove Compliance Controls
- 57. Logging
- 58. Monitoring for Misuse
- 59. Compliance Enquiries
- 60. Customer Internal Investigations
- 61. Reporting Suspected Misuse
- 62. Reporting Data Errors
- 63. Emergency Protective Action
- 64. Types of Restriction
- 65. Proportionate Enforcement
- 66. Serious Misuse
- 67. Supplier-Mandated Suspension
- 68. Legal and Regulatory Requests
- 69. Customer Liability
- 70. Departing Users
- 71. Public-Sector Customers
- 72. Regulated Customers
- 73. Geographic Restrictions
- 74. International Transfers
- 75. Sanctions and Illegal Activity
- 76. No Rights Created by Accidental Access
- 77. Changes to this Policy
- 78. Questions About Whether a Use Is Permitted
- 79. Final Principle
- 80. Contact
This Acceptable Use Policy sets mandatory rules for using KleipData. It forms part of the KleipData Agreement and should be read with the Terms of Service and the Privacy Policy.
1. Purpose of this Policy
This Acceptable Use Policy ("AUP") establishes mandatory rules for use of:
- a. the KleipData website;
- b. the KleipData Platform;
- c. customer and developer portals;
- d. KleipData APIs;
- e. Search Services;
- f. KYC and verification Services;
- g. Service Data;
- h. reports and exports;
- i. Sandbox environments;
- j. bulk and enrichment Services; and
- k. any other KleipData functionality subject to this Policy,
together referred to as the "Services".
This Policy is designed to protect:
- a. individuals whose information may be processed through KleipData;
- b. KleipData Customers;
- c. data Suppliers;
- d. the integrity of the KleipData Platform;
- e. security;
- f. privacy;
- g. contractual rights; and
- h. lawful use of data-intelligence Services.
2. Who Must Comply
This Policy applies to:
- a. Customers;
- b. Organisations;
- c. Organisation administrators;
- d. Authorised Users;
- e. developers;
- f. investigators;
- g. compliance users;
- h. API Applications;
- i. contractors acting for a Customer;
- j. service accounts;
- k. systems using KleipData credentials; and
- l. anyone else accessing or using the Services.
An Organisation is responsible for ensuring that people and systems using its Account comply with this Policy.
3. Relationship With the Terms of Service
This AUP forms part of the KleipData Agreement.
It should be read with:
- a. the KleipData Terms of Service;
- b. the Data Use Schedule;
- c. the API Terms;
- d. the Privacy Policy;
- e. the applicable Data Processing Addendum;
- f. the Customer NDA;
- g. Dataset-Specific Terms;
- h. the applicable Order Form; and
- i. other contractual conditions applying to the Customer.
A use may be technically possible but contractually prohibited.
Technical access does not create legal permission.
4. Core Acceptable-Use Rule
You may use KleipData only where each of the following is satisfied:
- a. the Organisation is authorised;
- b. the user or application is authorised;
- c. the Service is authorised;
- d. the dataset is authorised;
- e. the operation is authorised;
- f. the purpose is legitimate and lawful; and
- g. the applicable contractual conditions are satisfied.
If any of those requirements is absent, you must not conduct the Search or processing activity.
5. Legitimate Organisational Use
Subject to entitlement, applicable law and Dataset-Specific Terms, legitimate uses may include activities such as:
- a. identity verification;
- b. address verification;
- c. historical address enquiries;
- d. residency verification;
- e. KYC;
- f. fraud prevention;
- g. fraud investigation;
- h. public administration;
- i. statutory functions;
- j. authorised housing and casework functions;
- k. corporate due diligence;
- l. company and officer searches;
- m. authorised property research;
- n. customer onboarding;
- o. legitimate compliance enquiries;
- p. safeguarding activity where legally justified;
- q. lawful debt or asset enquiries;
- r. claims and litigation support where legally justified;
- s. data-quality improvement;
- t. authorised Customer-record enrichment;
- u. evidence and casework activity;
- v. supported CRM or case-management integration; and
- w. other purposes expressly authorised by KleipData.
Availability of a Service does not establish that every Customer has authority to use it for every one of these purposes.
6. The Customer Must Establish Its Own Authority
Before using Service Data concerning an individual, the Customer is responsible for establishing its own legal and organisational authority.
Depending upon the use case, this may involve:
- a. a lawful basis under data-protection law;
- b. statutory powers;
- c. statutory duties;
- d. contractual necessity;
- e. legitimate interests;
- f. recognised legitimate interests;
- g. legal obligations;
- h. appropriate consent;
- i. litigation requirements;
- j. crime-prevention grounds; or
- k. another lawful basis.
KleipData does not grant statutory powers to a Customer.
KleipData’s contractual permission to access information does not replace legal authority required by the Customer.
7. Purpose Declarations
Where KleipData requires a purpose to be recorded, you must provide a truthful and meaningful purpose.
You must not:
- a. enter a false purpose;
- b. enter a fictitious case reference;
- c. reuse an unrelated case reference;
- d. describe personal curiosity as business activity;
- e. select an incorrect statutory purpose merely to obtain access;
- f. deliberately choose the least restrictive purpose option;
- g. conceal the true reason for a Search; or
- h. provide misleading information to circumvent access controls.
A false purpose declaration may itself be treated as serious misuse.
8. No Personal Curiosity Searches
You must not search for a person merely because you are:
- a. curious about them;
- b. acquainted with them;
- c. related to them;
- d. in a personal dispute with them;
- e. considering entering a personal relationship with them;
- f. attempting to discover where they live;
- g. interested in their family;
- h. interested in their assets;
- i. interested in their history; or
- j. otherwise acting for a private purpose unrelated to the authorised work of the Organisation.
Access to KleipData is not a licence to investigate anyone you choose.
9. No Searches for Friends, Family or Colleagues Without Legitimate Authority
You must not use KleipData to search:
- a. yourself;
- b. a colleague;
- c. a manager;
- d. an employee;
- e. a former employee;
- f. a spouse or partner;
- g. a former spouse or partner;
- h. a family member;
- i. a neighbour;
- j. a friend;
- k. a prospective romantic partner;
- l. a public figure; or
- m. any other personally known individual
unless the Search forms part of a genuine, authorised organisational process and all applicable legal and contractual requirements are satisfied.
10. No Stalking or Harassment
You must not use KleipData:
- a. to stalk someone;
- b. to harass someone;
- c. to locate someone for harassment;
- d. to monitor an individual’s movements for an unauthorised purpose;
- e. to repeatedly contact someone who has requested no contact;
- f. to intimidate;
- g. to threaten;
- h. to facilitate coercive control; or
- i. to facilitate abuse.
Any suspected use of KleipData for stalking, harassment or abuse may result in immediate suspension.
11. Domestic Abuse and Coercive Control
You must never use KleipData to:
- a. locate a victim or survivor of domestic abuse;
- b. identify a protected or confidential address;
- c. monitor a partner or former partner;
- d. identify people associated with a victim;
- e. trace a victim’s family;
- f. circumvent protective arrangements;
- g. facilitate coercive control; or
- h. assist another person with such activity.
Where KleipData reasonably suspects this type of misuse, access may be suspended immediately without prior notice.
12. No Doxxing
You must not use Service Data to:
- a. publish someone’s home address;
- b. publish telephone details;
- c. expose identifying information;
- d. facilitate online harassment;
- e. encourage others to contact a person;
- f. expose private information for retaliation; or
- g. otherwise "dox" an individual.
Lawful disclosure within an authorised case or professional process is different from public publication.
13. No Identity Theft
You must not use KleipData to obtain information for:
- a. identity theft;
- b. account takeover;
- c. impersonation;
- d. fraudulent applications;
- e. document fabrication;
- f. security-question discovery;
- g. payment fraud;
- h. benefit fraud;
- i. credit fraud;
- j. social engineering; or
- k. another dishonest purpose.
14. No Fraud or False Representation
You must not:
- a. misrepresent who you are;
- b. impersonate another Organisation;
- c. claim authority you do not possess;
- d. fabricate a Customer relationship;
- e. submit false verification information;
- f. manipulate Search criteria to deceive another person;
- g. use Search Results to support a knowingly false statement;
- h. provide false onboarding information; or
- i. otherwise use the Services dishonestly.
15. No Unlawful Obtaining or Disclosure of Personal Data
You must not knowingly or recklessly:
- a. obtain personal data without lawful authority;
- b. disclose personal data without authority;
- c. procure unauthorised disclosure;
- d. retain data where continued retention is not authorised;
- e. purchase access for someone who is not entitled to receive it; or
- f. facilitate another person’s unlawful access to Service Data.
The fact that a valid KleipData login was used does not automatically make the underlying obtaining or disclosure lawful.
16. No Unauthorised Surveillance
KleipData must not be used for covert surveillance of individuals except where the Customer has lawful authority and the particular use is expressly permitted by the Agreement.
You must not use KleipData as a substitute for a warrant, statutory authorisation or other legal authority that the Customer is required to obtain.
17. Vulnerable Individuals
Particular care must be taken where a Search concerns:
- a. a child;
- b. a victim of crime;
- c. a witness;
- d. a survivor of domestic abuse;
- e. a person in protected accommodation;
- f. a person subject to safeguarding arrangements;
- g. a person with a confidential address; or
- h. another person whose location or information could create heightened risk.
The Customer must ensure that access is genuinely necessary and appropriately authorised.
18. Children
You must not search for information concerning a child merely because the information may technically be available.
Processing involving children must be:
- a. necessary;
- b. proportionate;
- c. lawful;
- d. connected to an authorised organisational purpose; and
- e. subject to any enhanced safeguards required by law.
19. Discrimination
You must not use KleipData to discriminate unlawfully on the basis of a protected characteristic or another legally prohibited ground.
Service Data must not be used to create discriminatory proxies designed to evade equality or anti-discrimination requirements.
20. Significant Decisions
Where Service Data contributes to a decision having substantial consequences for an individual, you must apply appropriate verification.
Examples may include decisions concerning:
- a. housing;
- b. tenancy;
- c. employment;
- d. credit;
- e. eligibility;
- f. access to a public service;
- g. enforcement;
- h. fraud classification;
- i. benefits;
- j. safeguarding intervention; or
- k. another consequential outcome.
A single Search Result should not automatically be treated as conclusive evidence where reasonable verification is required.
21. Automated Decisions
You must not use the KleipData API to create an unlawful solely automated decision-making system.
Where applicable law requires:
- a. human intervention;
- b. an explanation;
- c. representations from the affected person;
- d. reconsideration; or
- e. an appeal mechanism,
the Customer remains responsible for providing those safeguards.
22. Facts, Matches, Associations and Inferences
You must preserve the distinction between:
- a. facts;
- b. observations;
- c. matches;
- d. address associations;
- e. inferences;
- f. confidence indicators; and
- g. verification results.
You must not deliberately transform a weaker form of evidence into a stronger assertion.
23. Address Associations
A shared-address observation does not automatically establish that two people are:
- a. spouses;
- b. civil partners;
- c. romantic partners;
- d. relatives;
- e. financially associated;
- f. members of the same household; or
- g. otherwise legally connected.
You must not represent an address association as a family or financial relationship unless the available evidence genuinely establishes that relationship.
24. Historical Information
Historic information must be treated as historic.
You must not knowingly present a historical address, telephone number, company role or other record as current where the available data indicates otherwise.
25. Accuracy
If you know or reasonably suspect that information is inaccurate, you must not continue presenting it as verified fact.
Where appropriate, you should:
- a. verify the information;
- b. record that it is disputed;
- c. seek correction;
- d. restrict reliance upon it; or
- e. use another source.
26. Direct Marketing
Service Data must not be used for mass direct marketing unless:
- a. the specific Service is licensed for that purpose;
- b. the Customer has the necessary data-protection lawful basis;
- c. PECR requirements are satisfied;
- d. Dataset-Specific Terms permit it; and
- e. the activity is expressly within the Customer’s entitlement.
The ability to retrieve a telephone number or email address does not constitute marketing consent.
27. Suppression and Objection Rights
Where an individual has lawfully objected to direct marketing, Service Data must not be used as a mechanism to circumvent that objection.
You must not intentionally reacquire alternate contact information through KleipData solely to continue marketing to a person who has opted out.
28. No Resale Unless Expressly Authorised
Customers must not:
- a. resell KleipData Searches;
- b. sell raw Service Data;
- c. offer third parties access to the Customer’s Account;
- d. create a public people-search service;
- e. provide Search Results commercially to unrelated third parties;
- f. sublicense datasets; or
- g. otherwise operate as a reseller
unless an applicable Order Form expressly grants that right.
29. Permitted Professional Disclosure
The prohibition on resale does not prevent lawful disclosure of specific information where necessary for an authorised purpose.
Examples may include disclosure to:
- a. a court;
- b. legal advisers;
- c. auditors;
- d. authorised contractors;
- e. processors;
- f. another public body where lawful;
- g. an affected person; or
- h. another authorised recipient,
provided applicable legal, contractual and Dataset-Specific requirements are satisfied.
30. No Database Reconstruction
You must not systematically extract Service Data for the purpose of:
- a. reconstructing a KleipData database;
- b. reconstructing a Supplier database;
- c. creating a competing data service;
- d. creating a permanent mirror of KleipData;
- e. bypassing future KleipData Searches;
- f. accumulating large volumes without a genuine operational requirement; or
- g. circumventing Usage charges.
Lawful retention of Search Results for genuine casework is not the same as database reconstruction.
31. No Speculative Bulk Collection
You must not conduct bulk Searches merely because information might be useful at some unspecified future point.
Bulk or enrichment processing must relate to a defined, authorised and lawful purpose.
32. Data Minimisation
You should search for and retain only information reasonably required for the authorised purpose.
Where a narrower Search can achieve the purpose, you should not unnecessarily obtain substantially more information.
33. Retention
Contractual permission to retain Service Data does not authorise indefinite personal-data retention.
Customers must maintain appropriate retention policies.
Where a case ends or a purpose expires, the Customer must consider whether continued retention remains justified.
34. Exported Data
Once Service Data is exported into a Customer system, the Customer remains responsible for:
- a. security;
- b. access controls;
- c. onward disclosure;
- d. retention;
- e. accuracy;
- f. individual rights; and
- g. eventual deletion.
Exporting data from KleipData does not remove the restrictions applying to it.
35. No Public Publication
You must not publish material quantities of Service Data through:
- a. a public website;
- b. a public API;
- c. social media;
- d. a public searchable database;
- e. an open data feed;
- f. an unrestricted shared drive; or
- g. another publicly accessible service
unless expressly permitted by KleipData and the applicable data rights.
36. AI and Machine-Learning Use
Unless expressly authorised in an Order Form, you must not use Service Data to:
- a. train a general-purpose artificial-intelligence model;
- b. fine-tune a third-party language model;
- c. create a commercial machine-learning dataset;
- d. contribute personal data to a publicly available model;
- e. build a competing identity or people-intelligence model;
- f. create embeddings intended to reconstruct the underlying data source; or
- g. supply Service Data to an AI provider for that provider’s own training.
This does not prohibit reasonable internal use of automation or AI where:
- a. the processing is lawful;
- b. Service Data is adequately protected;
- c. the provider does not acquire independent training rights;
- d. contractual restrictions are respected; and
- e. the processing remains within the Customer’s authorised purpose.
Where there is uncertainty, written approval should be obtained before using Service Data for model development or training.
37. No Scraping of the Portal
You must not use:
- a. web scrapers;
- b. crawlers;
- c. browser automation;
- d. headless browsers;
- e. robotic interaction;
- f. screen-scraping;
- g. automated form submission; or
- h. similar tools
to obtain information from the human-facing KleipData portal unless KleipData expressly authorises that method.
Automated access should use the KleipData API or another approved mechanism.
38. API Automation Is Permitted Subject to Controls
The fact that automated portal scraping is prohibited does not prohibit approved API automation.
API automation is permitted where:
- a. the Organisation has API access;
- b. the credential is authorised;
- c. the requested scope is authorised;
- d. the requested Service is authorised;
- e. rate and Usage limits are respected;
- f. each underlying processing activity has a legitimate purpose; and
- g. applicable law and Dataset-Specific Terms are satisfied.
39. API Credentials
API credentials are security credentials.
You must not:
- a. publish them;
- b. email active secret keys unnecessarily;
- c. share them publicly;
- d. commit them to a public code repository;
- e. embed secret keys in client-side JavaScript;
- f. expose them in screenshots;
- g. include them in support requests;
- h. share them with an unauthorised contractor; or
- i. otherwise make them available to an unauthorised person.
40. Credential Ownership
Production application credentials are associated with the Organisation and API Application.
An employee or contractor who creates a production credential must not treat it as their personal credential.
Where an individual leaves the Organisation, the Organisation must review that person’s access and associated credentials.
41. Compromised Credentials
If you know or suspect that a credential has been compromised, you must promptly:
- a. revoke or rotate it where possible;
- b. notify the appropriate Organisation administrator;
- c. notify KleipData where appropriate;
- d. investigate unauthorised Usage; and
- e. take reasonable steps to contain the incident.
Continuing knowingly to use a compromised credential may be prohibited.
42. No Credential Sharing Between Organisations
An API credential or user account issued to Organisation A must not be used to conduct Searches on behalf of Organisation B unless KleipData has expressly authorised the arrangement.
Customers must not create informal account-sharing arrangements to avoid separate contractual onboarding.
43. User Accounts
Human user accounts must not ordinarily be shared.
Each user should access KleipData using their own authorised identity so that:
- a. permissions can be applied correctly;
- b. activity can be audited;
- c. access can be revoked individually; and
- d. accountability can be maintained.
44. No Cross-Tenant Access
You must not attempt to:
- a. access another Organisation’s records;
- b. manipulate Organisation identifiers;
- c. change resource identifiers to test access;
- d. use another Organisation’s credentials;
- e. exploit authorisation weaknesses;
- f. retrieve another tenant’s cases; or
- g. circumvent tenant-isolation controls.
If you accidentally encounter information belonging to another Organisation, you must stop accessing it and notify KleipData promptly.
45. Security Testing
You must not conduct:
- a. vulnerability scanning;
- b. penetration testing;
- c. credential stuffing;
- d. password spraying;
- e. exploit testing;
- f. fuzzing;
- g. automated security probing;
- h. denial-of-service testing; or
- i. another intrusive security assessment
against KleipData without prior written authorisation.
Responsible security research must follow any applicable KleipData security-disclosure process.
46. No Unauthorised Access
You must not attempt to obtain access to:
- a. restricted accounts;
- b. restricted datasets;
- c. hidden endpoints;
- d. administrator functions;
- e. Supplier integrations;
- f. internal infrastructure;
- g. internal diagnostics;
- h. another Customer’s information; or
- i. systems for which you have no authorisation.
47. Rate Limits
You must comply with applicable rate limits.
You must not bypass them by:
- a. rotating API keys;
- b. using multiple user accounts;
- c. creating duplicate Organisations;
- d. distributing requests across IP addresses;
- e. using multiple Applications;
- f. intentionally fragmenting a workload; or
- g. another artificial mechanism.
48. Usage and Spending Limits
You must not intentionally circumvent:
- a. Usage quotas;
- b. Search limits;
- c. credit limits;
- d. spending limits;
- e. Service entitlements;
- f. concurrency controls;
- g. dataset restrictions; or
- h. account restrictions.
49. No Service Interference
You must not:
- a. overload the Platform;
- b. conduct a denial-of-service attack;
- c. intentionally degrade performance;
- d. interfere with another Customer’s use;
- e. transmit malicious requests;
- f. create excessive abandoned sessions;
- g. consume resources without legitimate purpose; or
- h. otherwise threaten Service stability.
50. Malware and Harmful Content
You must not use KleipData to transmit:
- a. malware;
- b. ransomware;
- c. viruses;
- d. malicious scripts;
- e. exploit code;
- f. credential-stealing software; or
- g. other harmful material.
51. Reverse Engineering
Except where a statutory right cannot lawfully be excluded, you must not:
- a. decompile;
- b. reverse engineer;
- c. disassemble;
- d. attempt to derive source code;
- e. reverse engineer proprietary API implementation;
- f. reverse engineer Supplier mappings; or
- g. attempt to discover confidential internal architecture
of the KleipData Platform.
52. Supplier Identity and Confidential Information
You must not use access to KleipData to:
- a. discover confidential Supplier arrangements;
- b. obtain wholesale pricing;
- c. identify restricted provider credentials;
- d. access Supplier accounts;
- e. reverse engineer provider mappings; or
- f. publish confidential Supplier information.
Where a Supplier is publicly identified, that does not grant rights to use the Supplier’s marks or imply endorsement.
53. Confidential Information
Confidential information obtained through KleipData must be protected.
You must not disclose:
- a. API secrets;
- b. security architecture;
- c. internal documentation;
- d. non-public commercial terms;
- e. confidential Supplier arrangements;
- f. internal credentials;
- g. proprietary methods; or
- h. other KleipData Confidential Information
except where authorised.
Service Data and Confidential Information are distinct categories, but both may carry restrictions.
54. Sandbox Environment
The Sandbox is for testing and development.
You must not:
- a. treat synthetic Sandbox subjects as real people;
- b. attempt to cause Sandbox requests to return unauthorised production data;
- c. use test credentials against production endpoints unless supported;
- d. use production credentials in unsafe test code; or
- e. attempt to bypass separation between Sandbox and Production.
55. Customer Applications
Customers integrating KleipData into another system must implement reasonable controls to ensure that their application does not make it easier to misuse KleipData.
Controls should be appropriate to the use case and may include:
- a. user authentication;
- b. role-based permissions;
- c. purpose capture;
- d. case-reference capture;
- e. API scope restrictions;
- f. audit records;
- g. Usage limits;
- h. retention controls;
- i. export controls; and
- j. administrator oversight.
56. Do Not Remove Compliance Controls
You must not design a Customer integration to intentionally:
- a. suppress purpose requirements;
- b. hide the identity of the requesting user;
- c. remove audit information;
- d. mask the true API Application;
- e. bypass Dataset-Specific Terms;
- f. circumvent user permissions; or
- g. defeat other compliance controls.
57. Logging
KleipData may log activity including:
- a. Organisation;
- b. user;
- c. API Application;
- d. request ID;
- e. Service;
- f. purpose;
- g. case reference;
- h. timestamp;
- i. source IP;
- j. response status;
- k. Usage; and
- l. provider transaction information.
Use of KleipData therefore should not be regarded as anonymous from the Organisation or KleipData.
58. Monitoring for Misuse
KleipData may use proportionate technical and organisational measures to identify:
- a. unusual Search patterns;
- b. suspicious credential activity;
- c. excessive searching;
- d. repeated searching for the same person;
- e. unexpected high-volume activity;
- f. access inconsistent with a user’s role;
- g. suspected data harvesting;
- h. attempts to circumvent controls;
- i. suspicious IP activity; or
- j. other indicators of misuse.
Automated detection may lead to review rather than being treated automatically as proof of wrongdoing.
59. Compliance Enquiries
Where reasonable, KleipData may ask a Customer to explain or evidence:
- a. the purpose of a Search;
- b. the authority for a Search;
- c. the relevant case;
- d. the user’s role;
- e. the lawful basis;
- f. statutory authority;
- g. retention;
- h. onward disclosure;
- i. unusual Usage; or
- j. another matter relevant to compliance.
The Customer must provide reasonable cooperation.
60. Customer Internal Investigations
Where misuse by an Authorised User is suspected, the Organisation should preserve relevant evidence and investigate appropriately.
The Organisation should not intentionally delete relevant audit or security information in order to frustrate investigation.
61. Reporting Suspected Misuse
Customers and users should promptly report suspected misuse to:
Reports should include sufficient information for KleipData to understand the issue.
Do not include active API secret keys in the report.
62. Reporting Data Errors
If you believe Service Data is materially inaccurate or incorrectly associated, you should report the issue rather than knowingly continuing to rely upon information you believe to be incorrect.
63. Emergency Protective Action
KleipData may immediately restrict access where necessary to protect:
- a. an individual;
- b. personal information;
- c. another Customer;
- d. a Supplier;
- e. the Platform;
- f. legal compliance; or
- g. security.
Advance notice may not be provided where doing so could increase the risk.
64. Types of Restriction
KleipData may respond to suspected or confirmed misuse by:
- a. blocking a request;
- b. requiring additional purpose information;
- c. restricting a dataset;
- d. restricting a Service;
- e. reducing API scopes;
- f. revoking a credential;
- g. disabling a user;
- h. suspending an API Application;
- i. suspending the Organisation;
- j. requiring compliance remediation; or
- k. terminating the Agreement.
65. Proportionate Enforcement
Not every breach will necessarily lead to Account termination.
When deciding what action is appropriate, KleipData may consider:
- a. seriousness;
- b. intent;
- c. risk to individuals;
- d. amount of data involved;
- e. recurrence;
- f. Customer cooperation;
- g. security implications;
- h. contractual obligations;
- i. Supplier requirements; and
- j. legal obligations.
Certain conduct may be sufficiently serious to justify immediate termination.
66. Serious Misuse
Examples of conduct likely to be treated as serious include:
- a. stalking;
- b. domestic-abuse facilitation;
- c. identity theft;
- d. deliberate fraud;
- e. deliberate unlawful data harvesting;
- f. sale of unauthorised personal data;
- g. deliberate cross-tenant access;
- h. credential theft;
- i. systematic database reconstruction;
- j. deliberate circumvention of compliance controls;
- k. intentionally false purpose declarations;
- l. malicious cyber activity; or
- m. repeated misuse after warning.
67. Supplier-Mandated Suspension
KleipData may be required to restrict a Service where an upstream Supplier reasonably determines that use is outside the applicable licence.
KleipData may investigate before permanently terminating access where circumstances allow.
68. Legal and Regulatory Requests
Where required by law, KleipData may preserve or disclose relevant information to:
- a. a court;
- b. law-enforcement authority;
- c. regulator;
- d. supervisory authority; or
- e. another competent authority.
Nothing in this AUP requires KleipData to notify a Customer where notification would be unlawful.
69. Customer Liability
The Organisation is responsible for activity carried out through its authorised users and systems as provided by the Terms of Service.
An Organisation should therefore maintain appropriate:
- a. onboarding;
- b. training;
- c. user access;
- d. role assignment;
- e. credential management;
- f. termination processes;
- g. audit review; and
- h. internal policies.
70. Departing Users
Where an employee, contractor or other Authorised User leaves or changes role, the Organisation should promptly review:
- a. portal access;
- b. Organisation membership;
- c. personal API credentials;
- d. administrator permissions;
- e. active sessions;
- f. application access; and
- g. any locally retained Service Data.
71. Public-Sector Customers
A public authority using KleipData remains responsible for identifying the legal power, duty or other lawful basis applicable to its activity.
Access to KleipData does not expand the statutory powers of a public authority.
A public-sector Customer must not conduct a Search merely because it would be administratively convenient if the underlying processing is not lawfully authorised.
72. Regulated Customers
Where a Customer is subject to sector-specific rules, use of KleipData must also comply with those requirements.
Examples may include requirements relevant to:
- a. financial services;
- b. legal services;
- c. housing;
- d. public administration;
- e. debt recovery;
- f. insurance;
- g. employment screening; or
- h. another regulated activity.
KleipData does not replace the Customer’s own regulatory compliance programme.
73. Geographic Restrictions
Certain datasets may be restricted according to:
- a. user location;
- b. Customer location;
- c. storage location;
- d. export destination; or
- e. another territorial licence condition.
You must not use technical measures to circumvent a geographic restriction.
74. International Transfers
Where a Customer exports personal data outside the United Kingdom, that Customer is responsible for determining whether the export is a restricted international transfer and for implementing any required safeguard.
A contractual right to export through an API does not remove data-protection transfer requirements.
75. Sanctions and Illegal Activity
You must not use KleipData where doing so would breach:
- a. applicable sanctions;
- b. export controls;
- c. court orders;
- d. prohibitions imposed by a competent authority; or
- e. other applicable law.
76. No Rights Created by Accidental Access
If KleipData accidentally makes a Service, dataset or function available beyond the Customer’s contractual entitlement, the Customer must not treat that error as creating a licence.
The Customer should notify KleipData where the discrepancy is apparent.
77. Changes to this Policy
KleipData may update this AUP to reflect:
- a. changes in law;
- b. new risks;
- c. new Services;
- d. new datasets;
- e. Supplier requirements;
- f. security developments;
- g. abuse patterns; or
- h. reasonable operational requirements.
Material changes affecting existing Customers will be handled in accordance with the Terms of Service.
78. Questions About Whether a Use Is Permitted
If a Customer is uncertain whether a proposed use falls within this AUP, it should seek clarification before conducting the activity.
Written clarification may be requested through:
KleipData may require additional information about the proposed purpose before confirming whether a use is permitted.
79. Final Principle
KleipData is designed to make legitimate data-intelligence work more effective.
It is not designed to remove the legal, ethical or professional responsibilities that apply to the Organisation using the information.
The controlling principle is:
Access only what you are authorised to access. Use it only for the authorised purpose. Retain only what you are lawfully entitled to retain. Disclose it only to people entitled to receive it. Protect it throughout its lifecycle.
80. Contact
Questions, security concerns or suspected violations of this Acceptable Use Policy may be reported to:
KleipData Operated by Computerko Limited 27 Old Gloucester Street London WC1N 3AX United Kingdom
Company Registration Number: 11125670
Email: support@kleipdata.co.uk
© 2026 Computerko Limited. KleipData. All rights reserved.