Vendor Due Diligence
AdTech vendor due diligence
Assess an AdTech vendor’s service, fees, integration, data access and exit terms against a defined Australian use case.
Assess an AdTech vendor against a defined use case, the evidence for its claims and the terms under which your team will operate or leave the service. Record essential requirements as confirmed, conditional or unconfirmed before approving a pilot or contract.
Define the decision
Name the inventory or audience, systems to connect, people who will operate the service and report needed to judge it. Give candidates the same essential questions.
For each answer, record the supporting document or demonstration, account-specific conditions and the person responsible for resolving gaps. A published feature does not establish access for your proposed account.
Check the commitments
| Area | Evidence to request | Decision |
|---|---|---|
| Service and control | Account roles, configuration walkthrough and responsibility map | Can your team direct and oversee the work? |
| Cost | Fee schedule, calculation bases and sample invoice | Can finance explain the total charge? |
| Integration | Current specifications, access requirements, limits and support route | Can the proposed systems connect and be maintained? |
| Data | Sample exports, field definitions and rights to use the records | Can you obtain what the decision requires? |
| Exit | Handover, transition assistance and access-closure terms | Can essential work continue if the service ends? |
A sample from another account can expose questions, but it does not prove your permissions or terms.
AdTech Vendor Due Diligence: Key Areas and Evidence Requirements
- Service and control
- Account roles, configuration walkthrough, responsibility map
- Cost
- Fee schedule, calculation bases, sample invoice
- Integration
- Current specifications, access requirements, limits, support route
- Data
- Sample exports, field definitions, rights to use records
- Exit
- Handover, transition assistance, access-closure terms
Map data and responsibility
Trace what enters the service, what it creates and who receives the outputs. Include tags, server events, audience files, settings, reports and downstream partners where relevant. Name an owner for each handoff and for investigating a failure.
Assess privacy handling against the APPs
The Australian Privacy Principles (APPs) are the cornerstone of the privacy framework in the Privacy Act 1988. They apply to any organisation or agency the Act covers, comprise 13 principles and are principles-based and technology-neutral.
Ask the vendor to explain how its privacy claims relate to the proposed service. A general compliance statement is not account-specific evidence.
Organise the review around the APP topics: collection, use and disclosure of personal information; governance and accountability; information integrity and correction; and individual access. For each topic relevant to the proposed integration, request the vendor’s description of its role, the service’s handling and the records or settings that support it.
For collection, use and disclosure, ask what information the service receives, what it uses it for and who may receive it. Compare the answer with the data flow for the proposed setup, including any outputs or onward transfers.
If a vendor’s explanation does not identify the handling for your account, record the gap. A general product description is not confirmation.
For governance and accountability, request the material that explains how the vendor oversees the handling of personal information in the service. Ask who can explain or resolve a discrepancy between the vendor’s stated practice and the configuration demonstrated for your account.
Keep this evidence distinct from your own organisation’s assessment of its responsibilities.
The OAIC states that a breach of an APP is an interference with an individual’s privacy and can lead to regulatory action and penalties.
Treat unresolved privacy claims as a decision issue. Record which evidence is missing, who will assess it and whether the gap must be resolved before a pilot or contract.
Privacy Handling Against the Australian Privacy Principles (APPs)
- ProsVendor provides account-specific privacy explanation; clear role in data handling; documented governance and accountability practices; alignment with APP collection, use, disclosure, integrity and access principles.
- ConsGeneral compliance statement only; no account-specific evidence; unclear data flow or ownership; missing documentation for governance or accountability; unresolved gaps in APP handling.
Establish the service footprint
Ask the vendor to identify where the proposed service stores or processes data, including any overseas components. Record the answer alongside the data flow so your team can understand where information goes, not just which systems connect. If the vendor cannot give an account-specific answer, mark the location as unresolved.
Australian laws set a baseline for Australian business operations even when servers or cloud providers are overseas. Overseas laws may also apply, depending on the business and its data handling. Ask the vendor to identify relevant operating entities and jurisdictions. Have your privacy or legal owner assess what that means for your organisation and arrangement.
Keep the vendor’s description of its footprint separate from your organisation’s legal assessment. That assessment should consider the proposed service, the information involved and the organisations handling it. Do not infer that data location alone answers which rules apply.
Steps to Establish the Service Footprint and Data Location
- Identify data storage and processing locationsRequest vendor-specific details on where data is stored or processed, including overseas components.
- Map data flow and handoffsTrace inputs, outputs, tags, server events, audience files, reports, and downstream partners.
- Identify relevant jurisdictions and entitiesDetermine operating entities and applicable laws, including overseas regulations.
- Conduct legal assessmentAssess implications for your organisation based on proposed service, data type, and handling parties.
Bound the pilot and decision
Specify the account, environment, permitted data, change owners, expected outputs, acceptance criteria and stop condition. Use authorised test records where possible.
A walkthrough can confirm settings; a pilot can assess only the setup and period actually observed. A report export does not prove that raw events or every historical field are available.
Mark each essential requirement confirmed only when the proposed arrangement has specific evidence. Mark a named outstanding permission or configuration conditional; mark an unsupported claim unconfirmed.
Ensure the contract and operating plan agree on fees, responsibilities, required data, support and exit assistance. Narrow or hold the commitment if an essential condition remains unresolved.
Essential Requirements for Pilot and Contract Approval
- Account and environment specificationConfirmed
- Permitted data types and sourcesConfirmed
- Change owners and responsibilitiesConfirmed
- Expected outputs and acceptance criteriaConfirmed
- Stop condition for pilotConfirmed
In this guide
- Asking vendors to explain each technology feeAsk an AdTech vendor to identify each fee’s service, calculation base and invoice evidence, then check what reports include.
- Reviewing data portability in an AdTech contractSpecify the AdTech records, formats, rights and handover timing needed to make a contract’s export promise usable.
- Checking integration documentation before a vendor pilotReview access, schemas, errors, quotas, versions and sample outputs before starting an AdTech vendor integration pilot.
- Planning an exit from a critical advertising vendorMap critical advertising dependencies, prepare a handover, stage a changeover and close data and access obligations.
