This document explains how the eFind Trust Framework is owned, reviewed, approved, versioned, and enforced. Governance is what turns a collection of well-written pages into a system that people can rely on: it names who is accountable, how a document moves from a draft to an approved rule, how changes are proposed and communicated, and what happens when a Policy is broken. We treat accountability and enterprise governance as operating requirements, not as paperwork.
The purpose of this document is to describe how the Trust Framework governs itself. A legal document is only as trustworthy as the process behind it. If nobody owns a policy, it drifts. If changes are made without review, they contradict each other. If updates reach the platform but never reach the people bound by them, the writing is worth very little. This Governance document sets out the rules that keep the framework accurate, internally consistent, current with Applicable Law, and honestly communicated to the people who depend on it.
It answers a set of practical questions. Who is responsible for each document? How does a document become official? What is the difference between a minor change and a material one? How do we tell an Advertiser, a Publisher, or a User that something has changed, and when can a change take effect immediately? What happens when two documents seem to conflict? How are vendors and Sub-processors held to the same standards we hold ourselves to? This document gives clear, enforceable answers.
This document governs every part of the Trust Framework: the overview and library index, the Master Definitions, the Writing Standards, the agreements, the privacy notices, and all product and platform Policies. It covers the people and roles inside eFind who create and maintain those documents, the lifecycle each document follows, the version numbering system, the change-control process, the way changes are communicated, the record-keeping we maintain, and the way conflicts and exceptions are resolved. It also governs how we hold third parties and Sub-processors to equivalent standards where they participate in delivering the Services.
This document describes internal governance and process. It is not itself an agreement between eFind and any customer, and it does not grant rights or remedies to any person. The binding commitments that customers and Users rely on live in the agreements and Policies, such as the Terms of Service, the Advertiser Agreement, the Publisher Agreement, and the Privacy Policy. Where this Governance document describes how those binding documents are maintained, the binding documents themselves always control the actual rights and obligations.
This document applies to the eFind teams and individuals who own, draft, review, approve, publish, and enforce the Trust Framework, including the Office of Trust and Legal and its stakeholders in product, security, privacy, and engineering. It also describes commitments that matter to Advertisers, Publishers, Users, developers, and business customers, because it tells them how the documents they rely on are kept accurate and how they will be notified of changes. Finally, it sets expectations that flow through to third parties and Sub-processors that support the Services.
Capitalized terms used in this document, such as Advertiser, Publisher, User, Policies, Applicable Law, Sub-processor, and Personal Information, have the meanings given in the Master Definitions. A few terms are specific to governance and are defined here where they first appear: the Office of Trust and Legal is the eFind function that owns the Trust Framework; a Document Owner is the person or team accountable for a specific document; a material change is a change that meaningfully affects a person's rights, obligations, risks, or the handling of their Personal Information; a minor change is any other change; and a change request is a proposal to add, alter, or retire a document.
We build the Trust Framework the way we build the Services: with the assumption that people will hold us to what we say. That assumption shapes everything below, and three principles run through this document.
The first principle is accountability. Every document has a named owner, every material change has an approver, and every version that goes live can be traced back to who drafted it, who reviewed it, and who approved it. When something is wrong, we want a clear answer to who is responsible for fixing it, not a diffuse sense that "the company" got it wrong. Accountability is not about assigning blame after a problem; it is about making responsibility clear before anything ships.
The second principle is a single source of truth. A given rule, definition, or commitment should exist in exactly one place, and everything else should point to that place rather than restating it. This is why the Master Definitions exist and why the Writing Standards require cross-references instead of copied text. When a rule lives in one place, it can be updated in one place, and it cannot fall out of sync with itself.
The third principle is that governance is a control, not a ceremony. The lifecycle, the version numbering, and the change-control process below are real gates. A document does not become effective because someone believes it is finished; it becomes effective because it has passed the steps that this document requires. We would rather move deliberately and be right than publish something we later have to retract.
Good governance depends on clear roles. The following roles carry defined responsibilities within the Trust Framework. A single person may hold more than one role, and a role may be held by a team rather than an individual, but the responsibilities themselves do not change.
The Office of Trust and Legal owns the Trust Framework as a whole. It is the final authority on the structure of the framework, the meaning of defined terms, the wording of legal commitments, and the process described in this document. It approves new documents, retires old ones, resolves conflicts between documents, and signs off on the version changes that move a document from draft to effective. It is also the office to which questions and concerns are directed. Where this document refers to "the Owner" of the framework, it means the Office of Trust and Legal.
Each individual document has a Document Owner: the person or team accountable for keeping that specific document accurate, current, and consistent with the rest of the framework. The Document Owner drafts changes, coordinates the reviews described below, and is the point of contact for questions about that document. The Office of Trust and Legal may act as the Document Owner for the core governance documents, and it assigns owners for product and platform Policies to the teams closest to the subject matter, always under its overall authority.
Legal documents describe how real systems and real products behave. For that reason, several stakeholder groups participate in review before a document can be approved:
These stakeholders do not each hold a veto over the framework, but a document cannot be approved as effective while a relevant stakeholder has raised an unresolved objection that a statement in it is inaccurate or unsafe.
Some decisions are too significant to rest at the working level. A material change that meaningfully alters the company's commitments, a conflict between documents that the Office of Trust and Legal cannot resolve within the framework, a decision to grant an unusual exception or waiver, and any change with substantial legal, financial, or reputational consequence are escalated to executive leadership for a decision. Executive leadership does not draft or edit the documents; it decides the questions of direction and risk that the process surfaces, and the Office of Trust and Legal then implements the decision through the normal lifecycle.
The single-source-of-truth principle is enforced through ownership. Because every document has an owner, and because a rule lives in exactly one document, there is always exactly one place where a change must be made and exactly one person or team accountable for making it. This prevents the most common failure of large legal frameworks, in which the same idea is written three ways in three places and slowly drifts apart until nobody can say which version is correct.
In practice this means the Master Definitions are the only place a defined term is defined, the Writing Standards are the only place the house style is set, the Privacy Policy is the only place our core privacy commitments are stated, and so on. Other documents reference these sources rather than restating them. When a document needs to use a term or a rule, it links to the owning document instead of copying language that might later change. The result is that updating a definition once updates its meaning everywhere it is used.
The published version of a document on ads.efind.com is the authoritative version. Drafts, internal copies, translations, and summaries are conveniences; if any of them conflicts with the published document, the published document controls. We do not maintain private side agreements that contradict the published framework.
Every document in the Trust Framework moves through the same lifecycle. A document may repeat parts of the lifecycle many times over its life as it is maintained, but it never skips the gates.
A document begins as a draft prepared by its Document Owner. The draft follows the Writing Standards from the start: plain English, the house style, correct use of defined terms, and cross-references to owning documents rather than copied text. During drafting, the owner gathers input from the relevant product, security, privacy, and engineering stakeholders so that the document describes reality rather than intention. A document in this state is a work in progress and is not published as effective.
When the draft is complete, it goes through internal review. Stakeholders confirm that it is accurate for their area, consistent with the rest of the framework, and free of conflict with another document, and the Document Owner resolves their comments. Internal review is where factual errors are caught: a statement that a control exists when it does not, a description of a feature that has changed, a definition used incorrectly. A document does not leave internal review with an unresolved accuracy objection open.
After internal review, the document is submitted to the Office of Trust and Legal for legal review. Legal review checks that the document is enforceable, that it is consistent with Applicable Law across the jurisdictions where the Services are offered, that it protects Users and customers as intended, and that its commitments are ones eFind can actually keep. Legal review may send a document back for changes, which restarts the relevant earlier steps.
Approval is the decision by the Office of Trust and Legal, with attorney sign-off, that a document is ready to take effect, and it is the gate that separates a draft from a live document. A document is not effective, and does not bind anyone, merely because it has been written or posted for review; it becomes effective only when it has been approved through this step and given an Effective Date.
Once approved, a document is published at its canonical location on ads.efind.com. Publication is what makes the document authoritative and available to the people bound by it. Where a change is material, publication is accompanied by the notice described later in this document.
Documents are living. Laws change, products evolve, and better wording is found. Maintenance is the ongoing work of keeping a document accurate through the change-control process. Every maintenance change re-enters the lifecycle at the appropriate point: a small wording fix may need only a light internal check, while a material change repeats internal review, legal review, and approval before it is published.
When a document is no longer needed, has been replaced, or has been merged into another, it is retired. Retirement is a deliberate act by the Office of Trust and Legal, not a silent deletion. A retired document is superseded on its Effective Date, our internal records are updated to reflect that it has been retired or replaced, and, where people relied on it, a pointer is left to the document that now governs the subject. We keep a record of retired versions so that the history of the framework can be reconstructed.
Version numbers are a control, and they carry a specific meaning in this framework. They are maintained in our internal change records rather than displayed on the published pages, and they tell us exactly how far a document has traveled through the lifecycle and how significant the most recent change was.
A document becomes Version 1.0 only after it has been approved by an attorney through the legal review and approval steps above. Reaching Version 1.0 is the moment a document stops being a draft and becomes an effective, binding part of the framework with a real Effective Date. No document reaches Version 1.0 by the passage of time or by being posted; it reaches that version only through approval.
After a document is at Version 1.0 or higher, later changes are numbered by their significance:
Changes to the framework are made through change control, not by ad hoc edits. Change control is the process that makes sure a change is proposed by someone accountable, reviewed by the right people, approved at the right level, and recorded.
Anyone inside eFind may raise a change request, and Users, Advertisers, and Publishers may prompt one by contacting the Office of Trust and Legal. A change request identifies the document to be changed, describes the proposed change, and explains why it is needed, whether that reason is a change in the law, a change in a product, a correction, or an improvement in clarity. The Document Owner takes the request and turns it into a concrete draft edit.
Every change is classified as minor or material, because the classification decides how much review it needs and how it must be communicated. The Document Owner proposes the classification and the Office of Trust and Legal confirms it, and when there is any real doubt about whether a change affects rights, obligations, risks, or Personal Information, we treat it as material. Material changes go through internal review, legal review, and the relevant stakeholder checks; minor changes go through a lighter internal check proportionate to their low risk, but they are still recorded.
A change is not live until it is approved. Material changes require approval by the Office of Trust and Legal with attorney sign-off, and, where the change is significant enough under the escalation rules above, a decision from executive leadership. Minor changes may be approved by the Office of Trust and Legal or the Document Owner under authority delegated by that office. Approval sets the new version number and the Effective Date, after which the document is published.
A change that people are bound by is meaningless if they are not told about it. How we notify people depends on whether the change is material and on who is affected.
For a minor change, we update the document and advance the version number in our records. We do not send a separate notice for every clarification or typo fix.
For a material change, we give affected Users, Advertisers, and Publishers advance notice before the change takes effect, using reasonable methods for the audience. Depending on the change and the audience, notice may be given by posting a prominent notice in the Services, by email to the address on an Account, by an in-product message, or by another method reasonably designed to reach the affected people. The notice describes what is changing and when the change takes effect, and we aim to give enough advance time that a customer can review the change and decide how to respond. The specific notice commitments that bind eFind to a particular customer are those stated in the applicable agreement, such as the Terms of Service, the Advertiser Agreement, or the Publisher Agreement, and this document does not reduce them.
Some changes cannot wait. A change that is required by Applicable Law, that is needed to respond to a legal or regulatory order, or that is security-critical, meaning it is needed to protect the safety or security of Users, customers, the Services, or others, may take effect immediately and before notice. When that happens, we still notify affected people as soon as we reasonably can and explain why the change took effect right away.
Governance only works if it can be checked, so we keep records of how the framework has changed over time. For each material change, and for the lifecycle of each document, our internal records are designed to show what changed, why it changed, who reviewed it, who approved it, which version number resulted, and when it took effect. This audit trail lets us reconstruct the state of any document as of any date and answer questions from customers, auditors, and regulators about what our commitments were at a given time.
We retain superseded versions of documents rather than discarding them, so that the history of a commitment is not lost when it is updated. Records are kept for as long as they are needed to meet our legal, regulatory, and operational obligations, consistent with the retention practices in the Privacy Policy where the records contain Personal Information. Access to the internal governance records is limited to the people who need it to do their work, in line with the Security Policy.
Even with a single source of truth, two documents can occasionally appear to say different things. When that happens, the conflict is resolved by a fixed order of precedence rather than by argument, so that the outcome is predictable.
The controlling rule is that the specific controls over the general. A document written to govern a particular subject, product, or relationship controls a general document on the same point, for the matter it specifically governs, and is understood to be the intended rule for its subject even if a more general document speaks to the topic in passing.
Where the specific-over-general rule does not settle the matter, the following order of precedence applies, with the higher item controlling the lower on the point in conflict:
If a genuine conflict cannot be resolved by these rules, the Office of Trust and Legal decides the correct reading and, where needed, corrects the documents through change control so that the conflict does not recur.
The Services are offered across jurisdictions, and the law is not the same everywhere. The framework is designed to stay aligned with Applicable Law in each place the Services are offered, and to do so without contradicting itself. We monitor legal and regulatory developments in the areas that affect the Services, including advertising, consumer protection, privacy and data protection, intellectual property, and emerging rules on artificial intelligence. When the law changes in a way that affects a document, the responsible team or the Office of Trust and Legal opens a change request, and the change moves through the lifecycle.
Where a legal requirement applies only in a particular jurisdiction, we generally address it in a document written for that jurisdiction, such as the California Privacy Notice or the GDPR Privacy Notice, rather than by changing the global documents in a way that would not fit everywhere. This keeps the core documents readable while still meeting local obligations. When Applicable Law and any document conflict, Applicable Law controls, as stated in the order of precedence above, and we update the affected document to remove the conflict.
Occasionally there is a good reason to depart from a Policy in a specific case: a supervised test, an accommodation, or a situation the Policy did not anticipate. Such departures are handled as exceptions or waivers, and they are the deliberate exception, not the quiet norm.
An exception or waiver is granted only by the Office of Trust and Legal, or by executive leadership where the escalation rules require it. It is documented in writing, with the reason for it, its scope, the person or Account it applies to, any conditions attached to it, and, wherever possible, an expiry date after which the normal rule applies again. A waiver is limited to the specific situation it addresses; granting it once does not change the underlying document and does not create a right to the same treatment in the future. If a pattern of exceptions shows that a Policy no longer fits reality, the correct response is to change the Policy through change control, not to keep waiving it.
Writing a Policy and enforcing it are different things, and a framework that is never enforced is not trustworthy. eFind enforces the Policies against Advertisers, Publishers, Users, and other participants who agree to them. The specific enforcement rights, remedies, and processes are set out in the binding documents themselves, such as the Terms of Service, the Advertiser Agreement, the Publisher Agreement, and the subject-specific Policies, and this Governance document does not add to or subtract from those rights; it describes how enforcement fits into governance.
When we identify a possible violation, we assess it against the relevant Policy. Depending on the nature and seriousness of the violation, the history involved, and Applicable Law, the response may range from a warning or a request to correct the problem, to limiting or pausing a Campaign, feature, or Placement, to withholding affected amounts, to suspending or terminating an Account, to reporting unlawful conduct to the authorities. We aim to make enforcement proportionate to the violation and consistent across similar situations, and we favor giving a participant the chance to fix a problem where doing so is safe and permitted. We reserve the right to act immediately, and without prior notice, where a violation is causing or threatening serious harm, where Fraud or Invalid Traffic is involved, or where Applicable Law or safety requires it.
Documents are reviewed on a schedule as well as in response to specific events. Each document in the framework is reviewed by its Document Owner and the Office of Trust and Legal at least once a year, and more often for documents in fast-moving areas such as privacy, security, and artificial intelligence. A periodic review checks that the document is still accurate, still consistent with the rest of the framework, still compliant with Applicable Law, and still written clearly under the Writing Standards. A review may conclude that no change is needed, in which case the review itself is recorded, or it may open change requests that then move through the lifecycle. Scheduled review does not replace the duty to change a document promptly when a specific event, such as a new law or a product change, requires it sooner.
The Services are delivered with the help of vendors and Sub-processors, and our commitments are only as strong as the weakest party who handles a customer's Content or a User's Personal Information. For that reason, we hold third parties and Sub-processors to standards equivalent to the ones this framework holds us to. Before a Sub-processor Processes Personal Information in connection with the Services, we assess it and put in place contractual obligations that require it to protect that information at a level consistent with the Privacy Policy, the Data Processing Addendum, and the Security Policy, and to Process it only under our instructions and for the purposes we permit. Where required, appropriate transfer mechanisms are used for any International Transfer.
We remain accountable for the parts of the Services we deliver, including the acts and omissions of our Sub-processors in that context, to the extent set out in the applicable agreements. Changes to the set of Sub-processors are handled under the Data Processing Addendum, including any notice and objection rights it provides. Where a third party is not a Sub-processor but still helps deliver the Services, we impose obligations appropriate to its role so that it does not become a gap in the framework.
The Office of Trust and Legal is the point of contact for questions about the Trust Framework and for reports that something in it is inaccurate, out of date, contradictory, or not being followed. If you believe a document is wrong, if you have spotted a conflict between two documents, if you are unsure how a Policy applies to you, or if you want to report a possible violation, we want to hear from you. Reports are reviewed, and where they identify a real problem, they are turned into change requests and moved through the process described above.
You can reach the Office of Trust and Legal at:
We will not penalize a User, Advertiser, or Publisher for raising a good-faith concern about the framework or for reporting a suspected violation. Where a concern relates to Personal Information or to your privacy rights, the Privacy Policy and the applicable privacy notices describe the additional ways you can contact us and the rights available to you.
Building Technology People Can Trust.
© 2026 eFind. All rights reserved.