ESRB Privacy Certified

The operator does not engage in behavioural advertising or targeted advertising to children based on child PI without VPC, and applies contextual-advertising-only configurations to child-directed products and the child-directed portions of mixed-audience products.

• Ad-stack configuration evidence (contextual only on child-directed)
• Documentation of any non-contextual ad processing with VPC

• Behavioural advertising on child-directed products without VPC

Mixed-audience operators implement a neutral age-screening mechanism that determines whether a user is a child without encouraging falsification, and treats users determined to be under 13 as subject to the child-directed protections.

• Age-screening flow design and neutrality evidence
• Routing logic for users determined to be under 13

• Age screening that encourages users to enter an age above 12
• No age screening on a mixed-audience product

Collection of precise geolocation information from children, and use of persistent identifiers beyond the Internal Operations Exception, are subject to Direct Notice and Verifiable Parental Consent, with disclosure in the privacy policy.

• Geolocation/persistent-identifier inventory and Direct Notice records
• Mapping of any persistent-identifier use to the Internal Operations Exception or VPC

• Collecting precise geolocation from children without VPC

Where a child-directed product permits collection of photos, video, audio or other user-generated content from children, the operator obtains VPC, applies moderation to limit disclosure of personal information by children, and disables features (e.g. open chat) that would otherwise enable such disclosure.

• VPC for photo/video/audio collection
• Moderation rules and tooling for UGC from children

• Open chat/UGC features on child-directed products without VPC and moderation

The operator collects from children only personal information that is reasonably necessary for the activity in which the child is participating, and does not condition the child's participation in a game/service on the child disclosing more PI than is reasonably necessary.

• Data-collection inventory mapped to specific activities
• Evidence of the no-conditioning rule applied to each activity

• Asking for unnecessary PI as a participation gate
• Persistent identifiers collected outside internal-operations exception scope

Where the operator relies on the Internal Operations Exception to collect persistent identifiers (or limited other PI) without VPC, it limits the use to support of internal operations as defined by COPPA (e.g. authentication, security, frequency capping, debugging, legal compliance), prohibits combining with other PI for outside-internal-operations uses, and records the basis.

• Internal Operations Exception scope per processing activity
• Controls preventing combination with other PI

• Using the exception for advertising or analytics beyond frequency capping

On parental request, and after reasonable verification, the operator provides the parent with a description of the types of PI collected from the child, the opportunity to refuse further use/collection, and the means to delete the child's PI; the operator does not condition continued participation on the parent providing more PI than reasonably necessary to honour the request.

• Parental-request intake and verification procedure
• Records of access/refusal/deletion actions

• No parental-deletion path
• Verification asking for unnecessary PI

The operator maintains a written retention policy and retains child PI only as long as is reasonably necessary to fulfil the purpose for which it was collected, and deletes the PI by reasonable measures designed to protect against unauthorised access/use in connection with its deletion.

• Written retention policy for child PI
• Secure deletion evidence at end of retention

• Indefinite retention of child PI
• Insecure disposal of records

The operator conducts due diligence on third parties (including software development kits, advertising networks and analytics providers) that have access to child PI to verify they support COPPA-compliant practices, and discloses such third parties and their data practices in the privacy policy and parental Direct Notice.

• SDK and third-party inventory with COPPA-compliance attestations
• Disclosure of third parties in the privacy policy and Direct Notice

• Embedding non-COPPA-compliant SDKs in child-directed products

The privacy policy clearly and completely describes the operator's personal-information practices: types of PI collected, how it is collected (active/passive), how it is used, disclosures to third parties (incl. SDKs), parental rights, contact information, the COPPA Safe Harbor (ESRB Privacy Certified) status, and the Internal Operations Exception where used.

• Online privacy policy meeting the COPPA 312.4(d) content list
• ESRB Privacy Certified status disclosure in the policy

• Privacy policy missing required disclosures
• No mention of COPPA Safe Harbor status

Before any collection, use or disclosure of personal information from a child the operator provides a Direct Notice to a parent describing the specific PI to be collected from the child, the operator's use and any disclosure of that PI, and the parental rights available, and seeks Verifiable Parental Consent.

• Direct-notice templates per processing activity
• Records of direct notices issued

• Collecting child PI before issuing a Direct Notice

The operator obtains Verifiable Parental Consent by an approved method (e.g. signed consent form returned by mail/fax/electronic scan, government-issued ID matching, credit/debit/payment-card transaction, knowledge-based authentication, face-match-to-photo-ID, video conference, or other FTC-approved method) before collecting/using/disclosing child PI, with exceptions per COPPA 312.5(c).

• VPC method documented per processing activity
• VPC evidence retained per parent
• Mapping of any 312.5(c) exception used

• Relying on email-only consent for non-internal-use processing
• No VPC records

Where there is a material change to a practice that was the subject of Direct Notice and VPC (e.g. new categories of PI, new disclosures, new uses), the operator provides updated notice to parents and obtains new VPC before applying the change to previously-collected child PI.

• Change-management process for child PI practices
• Records of re-notice and re-consent on material changes

• Material changes applied retroactively without re-consent

Membership in ESRB Privacy Certified requires an operator that is, or that processes personal information on behalf of an operator that is, a COPPA-covered entity, and selection of the applicable seal: the ESRB Privacy Certified Seal (general audience) or the ESRB Privacy Certified Kids Seal (child-directed). Members sign a contractual agreement with ESRB and submit each product/service for certification review.

• EPC membership agreement and seal selection record
• COPPA-coverage assessment for each certified product

• Using the seal on a product not submitted for certification
• Selecting the wrong seal for a child-directed product

Each product or service to be certified undergoes ESRB's comprehensive privacy assessment, including review of privacy policy disclosures, data flows, parental notice and consent mechanisms, security policies and the SDKs/third parties used. The member cooperates with the assessment by providing policies, access for testing and other requested information.

• Assessment-pack provided to ESRB (policies, data flows, SDK list)
• Resolution of ESRB findings prior to certification

• Certifying a product without resolving ESRB findings

ESRB provides each member with at least two compliance reports per certified product per year and conducts spot audits; certifications are subject to annual recertification with re-submission and re-review against the current Member Guidelines.

• ESRB compliance-report responses
• Annual recertification submissions
• Spot-audit cooperation evidence

• Lapsed annual recertification
• No record of ESRB report responses

Use of the ESRB Privacy Certified Seal or Kids Seal is permitted only on certified products/services in accordance with ESRB's seal-usage rules and only while the certification is current. Misuse or misrepresentation of the seal triggers ESRB enforcement and potential FTC referral.

• Seal-usage placement on certified products
• Removal of seal after lapse of certification

• Seal displayed after certification lapsed
• Seal applied to non-certified products

Members participate in ESRB's complaint mechanism, providing a published channel for users and parents to raise concerns about the member's privacy practices and cooperating with ESRB's resolution process within the prescribed timelines.

• Published complaint channel for the certified product
• Records of complaints received, escalated and resolved with ESRB

• No published complaint channel
• No tracking of ESRB-escalated complaints

The operator establishes and maintains reasonable procedures to protect the confidentiality, security and integrity of personal information collected from children, with a written information security programme covering administrative, technical and physical safeguards proportionate to the sensitivity of the information.

• Written information security programme
• Risk-assessment and safeguards for child-PI processing
• Vendor security obligations

• No written information security programme
• No safeguards specific to child PI

On a security incident involving child personal information the operator triggers its incident response, notifies ESRB as required by the Member Guidelines, and where applicable notifies the FTC, state attorneys general and affected parents under applicable law.

• Incident response plan covering child PI
• ESRB notification path documented
• Records of notifications to authorities/parents where required

• No ESRB notification path for child-PI incidents