Data Practices
How we research, verify, classify, store and correct data. Written plainly, so you can check whether it matches what you need before you send us anything.
How we research
We work across multiple research, enrichment, verification and public-data sources, chosen per project according to what the segment actually requires. Where a segment is not covered by existing sources, we research it directly rather than substituting a near approximation. The specific approach for your project is agreed in scope before work starts.
How we verify
Contact data passes through the verification workflow agreed for the project. Verification is a defined sequence of checks, not a single lookup, and its result is attached to each record rather than summarised at file level.
How we handle catch-all records
A catch-all domain accepts mail for addresses that may not exist, so a positive server response is not evidence that a mailbox is real. Catch-all records receive additional checks and are classified separately. They are never marked Verified on the strength of a catch-all response alone.
How we classify uncertainty
Every record is returned as Verified, Risky or Not Found. Verified passed the agreed checks. Risky means something was found but confirmation is incomplete, and the reason is identified. Not Found means we could not confirm it reliably — we return it as unknown rather than filling the gap with a guess.
How we handle client-provided data
Data you send us is used only for the project you sent it for. It is not merged into any other client’s deliverable and it is not resold. Access is limited to the team members working on your project.
Data quality and QA
Research and review are separate steps. Deliveries are checked against the criteria agreed in scope — duplicates, role relevance, company match, field completeness — before they leave. Larger projects are reviewed by sampling, with defect categories tracked so quality is measured rather than asserted.
Data traceability
Projects can include structured traceability fields — research date, verification date, verification status, source type and verification method — so you can see where a record came from and when it was last checked. The exact fields available depend on the sources used for that project and are agreed in scope.
Suppression and exclusions
Records you ask us to exclude are held on a suppression list for your account and checked against future deliveries, so a contact you removed is not reintroduced by a later project. Send exclusions at any point in an engagement.
Data corrections
If a delivered record is wrong, tell us and we will re-check it. Where the project scope includes replacement, we research an alternative contact at the same account. Corrections are handled as part of the engagement, not as a separate purchase.
Data retention
Project data is retained for the duration of the engagement and for a defined period afterwards so that refresh and correction requests can be honoured. You can ask us to delete your data earlier — write to us and we will confirm when it is done.
CRM access and security
Where a project requires access to your CRM, access is granted to named team members at the minimum permission level needed for the work. We do not use shared credentials. Before any write operation we take a full export, start with a limited batch, and keep bulk changes traceable and reversible. Access is revoked at project close where appropriate.
Contact us about data
Questions about how your data is handled, a correction request, or a request to be removed from a dataset — write to contact@prospectal.io and we will respond directly.