Observable infrastructure
Datazag focuses on public internet signals such as domains, DNS, certificates, hosting, ASN context, routing and provider footprints.
Trust & Governance
Use infrastructure intelligence you can inspect and govern.
Datazag products are built around observable internet infrastructure, explainable evidence, controlled product scope and clear licensing boundaries.
This page explains the trust model behind reports, alerts, APIs, data shares, marketplace datasets and partner-delivered services.
Buyer assurance
Evidence, scope and license clarity
Trust comes from knowing what is included, what is excluded, how output can be used and where human review or contractual approval is needed.
Trust dimensions
Evidence
Reason codes
Licensing
Privacy
False positives
Data shares
Partner use
Governance
Trust principles
How we earn trust
We understand buyers need more than a data feed. They need to understand what evidence supports the output, how it can be used and where the boundaries sit. Most importantly, we understand you want to stay in control of what you share with us.
Evidence over black boxes
Reports, alerts and enrichment outputs include evidence, reason codes and context so teams can inspect why a finding exists.
Product-specific scope
A free report, alert, API response and data share do not expose the same fields. Each product has its own scope, use case and delivery controls.
Clear licensing boundaries
Datazag separates internal intelligence operations from sellable data products, partner services and marketplace-ready outputs.
What customers can inspect
The evidence behind reports, alerts and data products.
The exact fields vary by product, but Datazag output is designed to expose enough context for a buyer to understand and challenge the result.
Observed facts
Domain, DNS, certificate, mail, hosting, ASN, prefix, registrar and provider context that supports a report or alert finding.
DomainsDNSCertificatesASNProviders
Reason codes
Readable explanations of why a domain, IP, infrastructure relationship, platform pattern or posture issue was considered relevant.
Risk reasonsPosture reasonsAlert reasonsEvidence fields
Confidence context
Signals that help teams decide whether to automate, block, investigate, de-escalate, monitor or route to human review.
ConfidenceSeverityRoutingReview path
Known-good and provider context
Cloud, CDN, mailbox, hosting, platform and customer-approved context used to reduce accidental over-classification.
CloudCDNMXNSAllowlists
History and change
Where included, point-in-time records and change history help buyers understand what changed and when it changed.
SnapshotsDeltasTime travelChange detection
Product controls
Different products expose different slices of the intelligence layer.
A report, alert, API response and cloud data share can draw on the same intelligence foundation, but each has its own field scope and intended use.
Reports
Designed for business-readable findings, DNS defense analysis, threat exposure, remediation priorities and portfolio summaries.
Alerts
Designed for operational delivery with alert class, reason codes, infrastructure context, recommended action and de-escalation paths.
API
Designed for real-time scoring and enrichment inside customer products, analyst workflows and partner platforms.
Cloud data shares
Designed for analytical joins, historical review, data science, threat hunting and marketplace-style consumption.
Partner services
Designed so MSSPs, ESPs and service providers can package intelligence into their own services without reselling raw data by default.
Licensing and permitted use
Built for operational use, not uncontrolled raw data resale.
Licensing should be simple to understand: use the intelligence in the contracted workflow, but do not redistribute raw data or extend rights to downstream partners without agreement.
Included by default
- • Use Datazag outputs inside the licensed product or workflow.
- • Use reports, alerts and enrichment to support internal decisions and customer-facing managed services where contracted.
- • Use permitted fields, schemas and delivery routes defined for the product purchased.
Not included by default
- • Raw data resale, bulk redistribution or standalone sublicensing.
- • Publishing Datazag data into another marketplace or public dataset.
- • Allowing downstream resellers, franchisees or channel partners to use or resell Datazag-powered services without written approval.
Handled by agreement
- • Partner-branded reporting and portal features.
- • Portfolio-wide or multi-client use cases.
- • Marketplace, data-share, white-label and downstream partner rights.
Privacy and customer context
External intelligence with clear customer-input boundaries.
Most Datazag products focus on externally observable infrastructure. Customer-supplied context is used to make the output more relevant and reduce noise.
Public internet data
Most intelligence products are built from externally observable infrastructure, not from customer inboxes, endpoint telemetry or private network traffic.
Report requests
For free reports, the submitted work email is used to derive the domain, process the request and deliver the report.
Marketing consent
Marketing follow-up should be separate from the processing needed to generate a requested report.
Customer context
Customer-supplied brands, domains, watchlists or approved baselines are used to make outputs more relevant to that customer.
False positives
Useful intelligence needs tuning and challenge paths.
Security teams need confidence that platform names, brand terms and provider patterns are not being treated as malicious without context.
Known-good infrastructure
Provider attribution, customer-approved infrastructure and common platform footprints help avoid obvious misclassification.
Context before action
A platform or brand term alone should not determine severity. DNS, certificate, hosting, history and relationship signals change routing.
De-escalation path
Operational products can include review and de-escalation workflows so accepted or known-good findings do not remain noisy.
Human-readable evidence
Reason codes and evidence fields give analysts and customers a way to challenge, validate or tune the output.
We have not published our false-positive numbers yet. We are measuring them, and we will publish them with the method. Until then, every alert shows its evidence, so you can judge it yourself — and tell us when we are wrong.
Marketplace and data-share boundaries
Data products are controlled at publish time.
Cloud marketplace and data-share buyers need to know what is included, what is excluded and what redistribution rights do not come with the product by default.
Derived intelligence
Marketplace and data-share products should expose derived Datazag intelligence, public infrastructure facts and product-approved context.
Restricted inputs
Internal-only feeds, restricted popularity data and raw third-party threat-feed rows are not published as standalone resale fields by default.
Schema discipline
Published datasets need explicit field scope, refresh cadence, historical coverage and licensing boundaries.
Buyer clarity
Customers should be able to understand what the dataset contains, how it can be used and what redistribution is not permitted.
Company and security posture
The company behind the intelligence.
Procurement needs to know who they are contracting with and how the company operates, not only how the data is produced.
Contracting entity
- Registered name
- Datazag Ltd
- Registered in
- England and Wales
- Company number
- 13217786
- Registered office
- 12 South Drive, Wokingham, England, RG40 2DH
- Incorporated
- 23 February 2021
Where your data goes, by delivery mode
Cloud share and marketplace
The dataset is delivered into your own cloud account and queried there. Your tables, your queries and your results stay in your environment. Nothing you join against our data is sent to us, and we cannot see it.
On this path Datazag is not a processor of your data: there is no processing agreement to negotiate for it, no international-transfer assessment, no sub-processor list to review, and no breach of ours that could expose it.
API
You send us domains to be assessed, so Datazag receives and processes what you send.
This path is a processing relationship and is governed by the data-processing agreement. The architectural argument above applies to the share path and does not extend to this one.
Certifications
Read this against the delivery model above: on the share path your data never reaches us, so the questions an assurance report usually answers about a processor do not arise for it.
Datazag does not hold SOC 2, ISO 27001 or an equivalent third-party assurance report today, and no assurance program is currently in progress. We would rather say so than imply otherwise.
What you can inspect instead:
- Every finding carries its reason codes and the observation it was read from, so outputs can be checked rather than trusted.
- Collection is limited to publicly observable internet infrastructure; the boundaries are published on this page.
- Product scope, permitted use and redistribution limits are contractual and stated, not implied.
- Security issues have a published route and a monitored mailbox — see Responsible Disclosure.
Answering vendor assessments
Send the questionnaire, security schedule or data-processing agreement and it reaches a person rather than a queue. Tell us the delivery mode you are assessing — share or API — because the answers differ, and the section above says how.
Next step
Use intelligence with evidence and boundaries.
Start with a report or alert workflow, then agree the product scope, delivery route and permitted use that fits your team, partner model or data-share requirement.