HomePractice AreasGDPRGDPR Consent for U.S. Businesses: A Comprehensive Guide to Articles 7 Through 10

GDPR Consent for U.S. Businesses: A Comprehensive Guide to Articles 7 Through 10

Contents

Why GDPR Applies to U.S. Businesses
Consent as a Legal Basis: An Overview
Article 7: Conditions for Consent
Article 8: Children’s Consent and Information Society Services
Article 9: Special Categories of Personal Data
Article 10: Criminal Convictions and Offences
Practical Compliance Checklist
Conclusion

Why GDPR Applies to U.S. Businesses

Many American companies are surprised to learn that the European Union’s General Data Protection Regulation (GDPR) — which entered into force on May 25, 2018 — creates binding legal obligations for businesses that have no physical presence in Europe whatsoever. This is not an oversight; it is the deliberate design of Article 3 of the Regulation, which establishes an expansive extraterritorial scope intended to protect the personal data of individuals located within the EU regardless of where the entity processing that data happens to be based.

Under the GDPR’s “targeting criterion,” a U.S. business is subject to the Regulation if it offers goods or services to individuals in the EU — even if no payment is involved — or if it monitors the behavior of individuals located in the EU, for example through website analytics, behavioral advertising, or location tracking. If your company runs a website accessible to European visitors, sells products to customers in Germany or France, operates a mobile application downloaded by EU residents, or tracks user behavior through cookies or pixels that reach European users, you are almost certainly within the GDPR’s scope. Penalties for non-compliance can reach up to €20 million or four percent of global annual turnover, whichever is higher, making this a risk that U.S. counsel cannot afford to ignore on behalf of their clients.

The GDPR requires that every collection and use of personal data be grounded in one of six lawful bases identified in Article 6. Consent is one such basis, and while it is not always necessary — legitimate interests, contractual necessity, and legal obligation are alternatives — it is frequently relied upon in practice, particularly in the context of marketing, cookie placement, and the processing of sensitive personal information. Understanding precisely what valid consent means under European law is therefore foundational to any U.S. company’s GDPR compliance program.

Consent as a Legal Basis: An Overview

The GDPR defines consent in Article 4(11) as “any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.” Each element of that definition carries significant legal weight, and the failure to satisfy any one of them renders the entire consent invalid.

U.S. businesses accustomed to permissive domestic privacy frameworks — including the notice-and-choice models that have historically characterized American data governance — will find the GDPR’s standard considerably more demanding. Under U.S. practice, an opt-out mechanism or a buried disclosure in a privacy policy has often been considered sufficient. Under GDPR, neither approach qualifies. European consent requires a positive, affirmative act by the individual before processing begins, not merely an absence of objection after the fact.

It is also important to understand what consent is not. Consent is not the same as notice. Telling a user about your data practices does not, by itself, create a lawful basis for processing their data. Consent is likewise not interchangeable with contractual terms; processing cannot be made a condition of service unless it is genuinely necessary to perform that service. And consent is not permanent — it can be withdrawn at any time, and when it is, processing for that purpose must cease without delay. These distinctions fundamentally shape how consent mechanisms must be architected, documented, and maintained by U.S. companies operating in European markets.

Key Point

Consent under GDPR is not a one-time checkbox. It is an ongoing legal relationship between your business and the individual, requiring robust record-keeping, genuine choice, and a clear withdrawal mechanism from the moment processing begins.

Article 7: Conditions for Consent

Article 7

Article 7 of the GDPR sets out the operational conditions that must be satisfied for consent to be valid and enforceable. It builds upon the general definition of consent in Article 4(11) and translates the definitional elements — free, specific, informed, unambiguous — into concrete requirements that controllers must fulfill in their systems and processes.

Demonstrability: The Controller’s Burden of Proof

Article 7(1) places the burden of proof squarely on the data controller — meaning the U.S. business — to demonstrate that consent was properly obtained. The provision states that where processing is based on consent, the controller shall be able to demonstrate that the data subject consented to the processing. This is not a passive obligation. It requires that companies proactively design their consent infrastructure to generate a durable, retrievable record that shows who gave consent, to what processing activities they consented, when consent was given, what information was provided to the individual at the time of consent, and through what mechanism the consent was expressed.

In practice, this means that a simple log entry confirming that a user clicked “Accept” is unlikely to be sufficient. Regulators will want to see what version of the consent notice was displayed at the time, whether there were pre-ticked boxes (which are prohibited), and whether the consent covered the specific processing later undertaken. U.S. companies should build consent management platforms or work with vendors that record these granular details and make them auditable. Failure to maintain these records not only creates regulatory exposure but also makes it practically impossible to honor a data subject’s request to know whether and how their data is being processed.

Presentation: Distinguishable and Intelligible

Article 7(2) addresses how consent requests must be presented when they form part of a broader document — most commonly, a terms of service or a privacy policy. The Regulation requires that a request for consent must be presented in a manner that is clearly distinguishable from the other matters contained in the document, in an intelligible and easily accessible form, using clear and plain language. Any part of a declaration that violates the GDPR is not binding on the individual.

For U.S. businesses, this provision has direct implications for the design of website policies and account registration flows. A consent request embedded deep within a multi-page privacy policy, presented in the same font and formatting as boilerplate legal text, does not satisfy this standard. Consent must stand apart visually and contextually. It must be easy for an ordinary person — not a lawyer — to find, read, and understand. The European Data Protection Board (EDPB) has issued guidance recommending that consent requests avoid technical jargon, use short, clear sentences, and never rely on double-negatives or confusing conditional language. These requirements are especially significant for companies that have historically drafted their privacy disclosures primarily for legal defensibility rather than consumer readability.

The Right to Withdraw: Ease and Equivalence

Article 7(3) grants individuals the right to withdraw consent at any time, and it imposes an important equivalence requirement: withdrawing consent must be as easy as giving it. This symmetry principle has profound implications for user interface design. If a user can opt in to marketing communications by clicking a single toggle on a dashboard, they must be able to opt out by the same mechanism. A company cannot offer a streamlined opt-in process and then require the individual to send a written request by email or navigate through multiple pages to withdraw. The withdrawal mechanism must be obvious, immediate, and equally frictionless.

When consent is withdrawn, processing must stop — but Article 7(3) clarifies that withdrawal does not affect the lawfulness of processing that occurred before the withdrawal took place. This temporal carve-out is important: businesses are not required to unwind historical processing that was lawful at the time it occurred, though they will typically need to cease future processing, delete or suppress the relevant data, and update any systems that continue to act on that data automatically.

Conditionality: The “Freely Given” Requirement

Article 7(4) addresses what it means for consent to be “freely given” — the element that most often trips up U.S. businesses accustomed to treating data collection as an implicit condition of service. The Regulation states that, when assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is made conditional on consent to the processing of personal data that is not necessary for the performance of that contract.

The practical import of this provision is significant. If a user must consent to receiving marketing emails in order to create an account, and that marketing processing is not necessary to deliver the service they signed up for, then the consent is not freely given — it is coerced, and therefore invalid. U.S. businesses must conduct a careful analysis to distinguish between data processing that is genuinely necessary to fulfill the contract (which can lawfully be processed under Article 6(1)(b) rather than consent) and processing for ancillary purposes such as profiling, advertising, or cross-platform tracking. The former does not require consent; the latter does, and that consent cannot be bundled into acceptance of general terms.

Common Mistake

Conditioning account creation or service access on consent to marketing, analytics, or third-party data sharing is one of the most frequently cited GDPR violations by European data protection authorities. It should be treated as a high-priority item in any compliance audit of U.S.-facing websites and applications.

Article 8: Children’s Consent and Information Society Services

Article 8

Article 8 of the GDPR introduces a specialized consent framework for children in the context of what the Regulation calls “information society services” — a broad category that encompasses most online platforms, apps, social networks, gaming services, e-commerce sites, and digital content providers. For U.S. businesses that operate consumer-facing digital products potentially accessible to minors in the EU, Article 8 establishes demanding and technically complex obligations.

Age Thresholds and Parental Authorization

The default rule under Article 8(1) is that processing personal data of a child under the age of 16 based on consent is only lawful if that consent is given or authorized by the holder of parental responsibility for the child. The Regulation permits EU Member States to lower this age threshold, but not below 13 — meaning that, depending on the jurisdiction, the relevant age at which a child can independently consent may be 13, 14, 15, or 16. As of the date of this writing, a number of EU Member States have exercised their right to lower the threshold, including France (15), Spain (13), Italy (13), and Portugal (13), while others such as Germany and the Netherlands have retained the default age of 16. U.S. businesses must therefore understand which Member States they are targeting and apply the appropriate age threshold for each.

This requirement has no direct equivalent in U.S. federal law for the range of services covered by the GDPR. While the Children’s Online Privacy Protection Act (COPPA) mandates verifiable parental consent for collecting personal information from children under 13, the GDPR’s framework applies to older children as well, and the standard for verifying parental consent — while not prescriptively defined — is informed by the overarching GDPR principle that consent must be genuine and demonstrable. Vague self-declaration by a parent (such as checking a box) is unlikely to satisfy the standard for high-risk processing contexts, such as behavioral profiling or targeted advertising directed at young users.

Reasonable Efforts to Verify Age

Article 8(2) obliges the controller to make “reasonable efforts” to verify that consent was given or authorized by the holder of parental responsibility, taking into account available technology. This is a proportionality-calibrated standard, not an absolute requirement of certainty, but it places a real burden on U.S. operators to implement age verification mechanisms that go beyond an honor system. Asking a user to enter a birthdate — which any child can falsify — is not generally considered a reasonable effort in isolation. More robust approaches include age estimation technology, credit card verification, or requiring a confirmed email from an adult account.

Article 8(3) preserves the general law of contract in EU Member States as it relates to child-protection law, meaning that national legal frameworks governing a minor’s capacity to enter contracts continue to apply alongside the GDPR. U.S. businesses should work with local European counsel to understand how these national-level rules interact with GDPR obligations in any given Member State where they are active.

Practice Note

U.S. businesses offering services that could appeal to users under 16 — including gaming, social features, content platforms, or any ad-supported free tier — should conduct a child-user risk assessment and implement age-appropriate design principles consistent with Article 8 before deploying in European markets.

Article 9: Special Categories of Personal Data

Article 9

Article 9 of the GDPR establishes a heightened protective regime for certain categories of personal data that the Regulation treats as inherently more sensitive — either because of the particular harms that can flow from their misuse or because of the fundamental rights and freedoms they implicate. Processing these categories is prohibited by default, subject to a specific list of exceptions. For U.S. businesses, many of which routinely handle data that falls within Article 9’s scope, this provision is among the most consequential in the entire Regulation.

The Special Categories

Article 9(1) identifies the following special categories: personal data revealing racial or ethnic origin; personal data revealing political opinions; personal data revealing religious or philosophical beliefs; personal data revealing trade union membership; genetic data; biometric data processed for the purpose of uniquely identifying a natural person; data concerning health; data concerning a person’s sex life; and data concerning a person’s sexual orientation. The breadth of this list may surprise U.S. businesses operating in sectors like human resources, healthcare technology, fitness, finance, or retail loyalty programs, where incidental collection of such data is common.

It is worth noting that the GDPR’s definitions here are functional rather than categorical. “Data concerning health” includes any information that relates to the physical or mental health of a natural person and which reveals information about their health status. A fitness app’s step-count data, an insurance form’s self-reported medical history, and a hospital’s treatment records all constitute health data under this standard. Similarly, facial recognition data used to identify individuals — as in many workplace access control systems increasingly deployed by U.S. technology companies operating in Europe — constitutes biometric data within Article 9’s scope. The consequences of misclassifying data and failing to apply the Article 9 framework can be severe, including some of the largest fines issued by European data protection authorities to date.

Explicit Consent as the Primary Exception

Article 9(2) provides ten grounds on which the general prohibition on processing special categories may be overcome. The first and most commonly relied upon by commercial U.S. operators is explicit consent: processing is permitted if the data subject has given explicit consent to the processing of those personal data for one or more specified purposes. The word “explicit” is critical — it is a more demanding standard than the ordinary consent required for non-sensitive data under Article 6. The EDPB has clarified that explicit consent typically requires a clear, affirmative statement or action specifically directed at the sensitive processing in question. A general consent to data processing will not, by itself, extend to cover processing of special category data. The individual must be clearly informed of the sensitive nature of the data and must actively and specifically agree to its collection and use.

For U.S. businesses, this means that obtaining explicit consent for special category data processing requires dedicated, targeted consent flows — not a single omnibus consent checkbox that covers all data practices. A healthcare platform, for instance, cannot rely on an account-creation consent to authorize both general analytics and the processing of health records. The latter requires its own specific, explicit consent mechanism, and the records of that consent must be maintained with the same rigor — indeed more so — as ordinary consent records.

Article 10: Criminal Convictions and Offences

Article 10

Article 10 of the GDPR creates a separate but related protective regime for personal data relating to criminal convictions and offences, or related security measures. Although this Article is brief, it has significant practical implications for U.S. businesses engaged in employee background screening, tenant screening, fraud prevention, financial services compliance, and any other activity that involves querying, receiving, or retaining criminal records or information about alleged criminal behavior.

Article 10 provides that processing of personal data relating to criminal convictions and offences, or related security measures based on Article 6(1), shall be carried out only under the control of official authority or when the processing is authorized by EU or Member State law providing for appropriate safeguards for the rights and freedoms of data subjects. Unlike Article 9, which includes consent as a recognized exception, Article 10 does not list consent among the grounds on which a private controller may lawfully process criminal records data. This is a deliberate choice. The sensitivity of criminal history information — and the asymmetric power relationships involved in its disclosure — led the GDPR drafters to restrict this processing to official authorities and to entities specifically authorized by law, rather than leaving it to individual-level consent agreements.

The practical effect for U.S. businesses is that private companies cannot lawfully process EU residents’ criminal history data simply by obtaining that person’s consent. If a U.S. employer wants to conduct criminal background checks on prospective EU-based employees, it must ensure that such processing is authorized under the law of the relevant EU Member State, and must process that data through proper official channels. Many EU Member States have enacted specific legislation governing when and how criminal records data may be accessed by private employers, often limiting checks to particular industries (such as childcare or financial services) and imposing strict retention and deletion rules. U.S. companies should seek country-specific legal guidance before building criminal screening into European HR workflows.

It should also be noted that Article 10’s scope extends beyond formal criminal convictions. The provision applies to data “relating to criminal convictions and offences or related security measures,” language that supervisory authorities have interpreted to include pending prosecutions, allegations not resulting in conviction, and in some cases civil fraud findings or professional disciplinary records where these are functionally equivalent to criminal sanctions. U.S. compliance teams designing fraud prevention or customer due diligence programs for EU markets should undertake a careful scoping exercise to determine whether their datasets trigger Article 10 obligations.

Practical Compliance Checklist for U.S. Businesses

The following checklist summarizes the key operational requirements that flow from Articles 7 through 10 of the GDPR. It is intended as a practical starting point for internal compliance review and should not be treated as legal advice or as a substitute for a tailored GDPR audit conducted by qualified privacy counsel.

Map all data collection touchpoints to identify where consent is the stated or intended lawful basis for processing, and confirm that consent is actually required (i.e., that no other lawful basis applies).
Audit existing consent mechanisms to ensure that pre-ticked boxes, implied consent, and bundled consent have been eliminated from all consent flows.
Implement a consent management platform or equivalent system capable of recording who consented, to what, when, through which mechanism, and based on which version of the consent notice.
Review all consent notices for plain-language compliance — ensure they are concise, free of jargon, written for a general audience, and clearly separated from other contractual or legal text.
Confirm that withdrawal mechanisms are equally prominent and frictionless as opt-in mechanisms, and that withdrawals are processed in real time across all systems that rely on the relevant consent record.
Remove any conditioning of service access on consent for processing that is not strictly necessary to provide that service.
Identify all services that may be used by individuals under 16 in EU markets and implement age-appropriate verification measures and parental authorization workflows.
Audit data inventories for special category personal data (including health, biometric, genetic, race, religion, political opinion, sexual orientation, and trade union data) and ensure that explicit consent — or a valid Article 9(2) exception — applies to each processing activity.
Review any criminal background screening or fraud prevention programs involving EU residents to confirm compliance with Article 10 and relevant national law authorizations.
Train all personnel responsible for product design, marketing, HR, and customer service on GDPR consent requirements and flag consent-related changes for legal review before deployment.

Conclusion

Consent under the GDPR is a substantive legal concept, not a procedural formality. For U.S. businesses operating in European markets, the consent framework established by Articles 7 through 10 demands a fundamental rethinking of how personal data is collected, described, managed, and ultimately processed. The days of treating a buried privacy policy, a pre-ticked opt-in box, or an omnibus account registration as a sufficient basis for wide-ranging data use are long past — at least with respect to EU residents.

The good news is that businesses that invest in building a genuine, rights-respecting consent architecture tend to benefit not only from regulatory compliance but also from greater consumer trust. Transparent data practices — clearly communicated, easily controlled, and honestly maintained — are increasingly a competitive advantage in global markets where privacy expectations are rising on both sides of the Atlantic.

The regulatory landscape is also continuing to evolve. The EDPB regularly issues guidance updating its interpretation of consent requirements, and enforcement decisions by national supervisory authorities across the EU provide ongoing insight into how Articles 7 through 10 are applied in practice. U.S. businesses should treat GDPR compliance not as a one-time project but as an ongoing program requiring regular review, adaptation, and legal counsel.

Our firm advises U.S. companies across industries on all aspects of GDPR compliance, including consent architecture, data mapping, privacy-by-design implementation, and regulatory response. If you have questions about how Articles 7 through 10 apply to your specific business model or data practices, we invite you to contact us to discuss your needs.