Vermont Act 171 compliance: what data brokers get wrong about registration and opt-out evidence
Sienna VanceApril 29, 2026
Key takeaways
Vermont Act 171 registration is triggered by selling or licensing personal information of Vermont residents to third parties without a direct consumer relationship -- the threshold is the commercial transaction, not the volume of data or the size of the organization.
SOC 2 certification does not satisfy Vermont Act 171 registration requirements. A SaaS company can pass a SOC 2 audit and still be operating as an unregistered data broker if it sells behavioral profile data to advertisers.
The Vermont AG's enforcement standard for opt-out compliance requires a documented, auditable process -- timestamped requests, confirmation records, deletion verification across active and archival systems. A CRM ticketing system with no audit export capability does not meet this standard.
Act 171's 'reasonable security measures' requirement applies to all consumer personal data the broker holds, not just payment data. PCI DSS compliance for credit card processing does not satisfy the Act's obligations for name, address, purchase history, and behavioral data stored separately.
Data retained in backups and cold storage after an opt-out request creates re-identification risk that the Act does not explicitly address -- but that regulators treat as a continuing compliance obligation based on the opt-out's intent.
18% of registered Vermont data brokers do not implement end-to-end encryption for data in transit, based on certificate transparency log analysis (Vulnox, 2024) -- a gap that is both a Section 9403(a) violation and a direct enforcement target.
TL;DR
Most Vermont Act 171 compliance failures happen before the security program is even relevant. Companies misclassify their activities, skip registration, and then invest in security controls for a compliance obligation they have not formally acknowledged. When the Vermont AG investigates, the first question is whether the organization was registered. The second is whether the opt-out process produces the audit trail that demonstrates compliance. Both questions expose the same structural gap: organizations built their data practices for operational convenience, not for regulatory evidence production, and those two designs are not the same.
The registration gap nobody notices until enforcement
A SaaS company providing marketing analytics to retail clients came into a Vulnox assessment with a SOC 2 Type II report issued six months earlier, a privacy policy referencing Vermont residents' rights, and a belief that their activities fell under the 'consumer credit reporting' exclusion in Vermont Act 171. Their product collected behavioral data -- browsing patterns, purchase intent signals, demographic inferences -- from end-user interactions on client websites, aggregated that data into audience segments, and sold access to those segments to advertisers. The legal team had classified this as market research. The AG's definition of a data broker includes any business that knowingly collects and sells or licenses personal information of Vermont residents to third parties with whom the business does not have a direct relationship. The advertiser buying the audience segment is a third party. The Vermont residents whose behavioral data populated that segment had no direct relationship with the SaaS company. The exclusion the company cited applies to consumer reporting agencies operating under the Fair Credit Reporting Act. It does not apply to behavioral profiling sold for advertising targeting.
The SOC 2 report documented security controls. It said nothing about whether the company was operating within the Act's registration scope. Those are different questions, evaluated by different parties for different purposes. The company had answered the security question and assumed the regulatory question was answered too.
What the Vermont AG actually needs to see during an opt-out investigation
Vermont Act 171 Section 9404(a) gives consumers the right to opt out of having their personal information sold or licensed. The mechanism for exercising that right must be accessible, and the broker must honor it. What the statute does not specify in detail is the evidence standard the AG applies when investigating whether opt-out requests were properly honored. That standard is reconstructed from enforcement practice and general regulatory expectations for data protection obligations. When the AG investigates an opt-out complaint, they are looking for four things: proof that the request was received and timestamped, proof that the consumer's identity was verified, proof that the data was removed from active processing systems, and proof that confirmation was sent to the consumer. The investigation may also ask about archival and backup copies -- whether data removed from active systems was also flagged for exclusion from future backup restoration. A company that cannot produce this evidence for a specific opt-out request from eight months ago has a compliance gap regardless of what its written policy says.
Example
The fintech client using a basic CRM ticketing system for opt-out tracking could demonstrate that tickets existed. It could not export a timestamped audit log showing when each ticket was received, when the data was removed, and when confirmation was sent. The tickets contained free-text notes from the analyst who handled each request. The notes were inconsistent. Some included confirmation dates. Some did not. Under the AG's evidence standard, that is not a documented, auditable opt-out process. It is documentation that an opt-out process sometimes happened.
The gap between 'we have a process' and 'we can prove the process ran for this specific consumer on this specific date' is an infrastructure gap, not a policy gap. It requires logging architecture that captures opt-out events as structured records with timestamps, user identifiers, action types, and system confirmations -- and that retains those records for a period covering the statute of limitations for AG enforcement actions. Most CRM systems can be configured to produce this. Most are not configured this way by default, and the configuration is treated as a product team decision rather than a compliance requirement.
Where Act 171 compliance breaks in practice
Assessment base: Vulnox Vermont Act 171 gap analyses and data broker compliance assessments, 2023-2025, covering e-commerce, fintech, SaaS, and marketing analytics companies
Registration scope misclassification in SaaS and analytics companies
Across Vulnox assessments involving SaaS companies with data monetization components, the most consistent finding is an incorrect exclusion determination. Companies providing analytics, audience intelligence, or data enrichment services classify their activities as market research, aggregated statistics, or operational data use -- categories that carry partial or full exclusions under Act 171. The classification analysis is conducted by legal teams reviewing the statute's exclusion language against a description of the company's product. It is not conducted by reviewing the actual data flows, the contractual structure of the data sale, and the identity of the purchaser relative to the Vermont residents whose data is involved.
Registration under Act 171 is required by January 31 of each year. A company that has not registered and is later found to meet the definition of a data broker faces enforcement action for the period of unregistered operation, not just for current practices. The misclassification is typically discovered during due diligence for an acquisition or during a regulatory inquiry, at which point the unregistered operating history is already established.
PCI DSS compliance treated as satisfying broader security obligations
An e-commerce client processing payments through a PCI DSS-compliant third-party gateway believed that the gateway's compliance satisfied Act 171's reasonable security measures requirement for consumer data. The gateway handled payment card data. The client's own systems stored names, email addresses, shipping addresses, purchase histories, and behavioral browsing data -- all personal information under Act 171 -- without the field-level encryption, access controls, or logging that PCI DSS requires for cardholder data. The security investment was concentrated on the payment channel because that was where the compliance certification existed.
Section 9403(a) requires reasonable security for personal information the broker holds. It applies to all personal data, not the subset that is also covered by another regulatory requirement. PCI DSS compliance is evidence that payment data was handled appropriately. It is not evidence that other consumer data in the same environment was handled appropriately. Auditors who review PCI DSS scope and assume it covers the Act 171 obligation are reviewing the wrong perimeter.
Opt-out archival gap creating ongoing re-identification exposure
Act 171's opt-out obligation requires that a consumer's data not be sold or licensed after the opt-out request is honored. The statute is silent on archival and backup copies. In Vulnox assessments, every organization that had an opt-out process had configured it to remove data from active production systems. None had configured it to flag the data in backup systems for exclusion from restoration, or to delete the data from cold storage archives on a defined schedule. The opted-out data exists in backup tapes, snapshot archives, and data warehouse historical partitions -- inaccessible for current processing but present in the environment.
A data breach involving backup systems exposes opted-out consumer data alongside current data. The consumer who exercised their opt-out right has no protection against this exposure. The AG's enforcement position on archival opt-out data has not been formally tested, but the gap is auditable and the risk is concrete. Organizations designing opt-out infrastructure should include archival systems in scope from the beginning -- retrofitting backup exclusion logic after the fact is technically complex and expensive.
Shadow IT data collection outside the registered broker's security perimeter
In two assessments, Vulnox found active data collection occurring through subdomains, third-party pixel integrations, and analytics SDKs that were not covered by the registered entity's security documentation. The registered data broker had documented its primary data collection infrastructure. Acquisition activity -- behavioral signals collected through partner integrations, affiliate tracking systems, and co-registration forms -- was routed through separate technical infrastructure operated by the same legal entity but not included in the security assessment scope.
The Act's reasonable security requirement applies to all personal information the broker holds, regardless of which technical system collected it. A security posture assessed against the primary infrastructure and applied to the registered entity does not cover shadow collection channels. The data from those channels has the same regulatory status. The security covering it is whatever the third-party vendor applied.
A Salesforce license is not a security control
Common belief
Organizations using enterprise SaaS platforms -- Salesforce, HubSpot, Marketo -- for consumer data management assume the platform's security certifications satisfy Act 171's reasonable security measures requirement. The platform has SOC 2. The platform has ISO 27001. The platform encrypts data. Therefore the data is secured.
What we found
The e-commerce client whose Salesforce instance was assessed had field-level encryption disabled on the fields storing consumer addresses and purchase history -- the fields most relevant to Act 171. Default sharing rules allowed any user in the org to view any contact record. The platform had a current SOC 2 Type II report. The instance configuration had never been reviewed against the Act's security requirements. The client's understanding was that Salesforce was a compliant platform. It is a platform that can be configured for compliance. Those are different.
Platform certifications document that the vendor's infrastructure meets a security standard. They do not document that the customer's configuration of that platform produces secure outcomes. Salesforce's SOC 2 report covers Salesforce's controls over the infrastructure it operates. It does not cover whether the customer enabled field-level encryption for sensitive data fields, whether access profiles were configured with least-privilege principles, whether API integrations were secured with appropriate token scopes, or whether the audit log was configured to capture the events relevant to Act 171 compliance. The default Salesforce configuration is designed for ease of adoption, not regulatory compliance. Field-level encryption is not enabled by default. Sharing rules are permissive by default. API access is broad by default. A company that purchased Salesforce and deployed it without security-specific configuration review has a platform with enterprise certifications and a customer instance that may fail Act 171's reasonable security standard.
What data brokers believe before the gap analysis, and what underlies it
'We have a QRadar SIEM. It's supposed to catch everything. Why is there a compliance gap in our logging coverage?'
Root cause:A SIEM captures events from the log sources that have been configured to feed it. It does not automatically discover and ingest logs from systems outside the configuration scope. Shadow IT services -- cloud storage buckets, analytics integrations, third-party data enrichment APIs -- generate events that are never routed to the SIEM because they were deployed without going through the IT onboarding process that would trigger log source configuration. The SIEM correctly reports on the environment it knows about. The compliance gap is in the environment it does not know about. QRadar does not audit its own blind spots.
'We process payments through a PCI-compliant gateway, so our consumer data handling is covered. Why are we being told we have a Vermont Act 171 security gap?'
Root cause:PCI DSS scope is defined by the payment card data environment. Data outside that environment -- which includes most of the personal information Act 171 covers -- is outside PCI DSS scope by definition. The gateway's compliance demonstrates that cardholder data was handled to PCI DSS standards. It says nothing about the security applied to the name, address, email, and behavioral data stored in the e-commerce platform's own database. Those fields, held by the broker, are what Act 171's Section 9403(a) reasonable security requirement covers.
'We're not really a data broker. We're a marketing analytics company. We provide insights, not raw data.'
Root cause:The distinction between selling insights and selling data does not map cleanly to Act 171's definition. The definition turns on whether personal information of Vermont residents is being sold or licensed to a third party without a direct consumer relationship. An audience segment derived from personal information is still personal information if it can be linked back to individuals -- which targeted advertising segments can be, by design, because the advertiser's goal is to reach specific people. The product framing as 'insights' or 'analytics' reflects how the company positions its offering commercially. It does not change what the data underlying the product is or who it is about.
Where Vermont Act 171 enforcement develops next
The Vermont AG will issue enforcement guidance specifically addressing data broker opt-out obligations for archival and backup systems within 24 months, driven by a breach disclosure in which a registered broker's backup environment exposed data belonging to consumers who had previously exercised opt-out rights.
The archival gap is structurally inevitable given how opt-out processes are currently implemented. Backup systems are not included in opt-out scope in any assessed organization. A breach involving backup data that includes opted-out consumers creates a concrete enforcement trigger. The AG's response will need to address whether the opt-out obligation extends to archival copies, and whatever guidance emerges will establish the standard retroactively for all registered brokers.
Confidence: mediumAG enforcement action or formal guidance addressing backup and archival opt-out obligations published before May 2027. Absence of any such guidance by that date suggests the gap is not yet being formally pursued.By Q3 2027, at least one enforcement action will target a company that was unregistered as a data broker while holding a current SOC 2 certification, establishing that security certification does not substitute for registration compliance and creating a reference case that reshapes how compliance teams assess registration scope.
The pattern of SOC 2-certified companies misclassifying their data broker status is consistent across Vulnox assessments. SOC 2 auditors do not assess whether a company meets Vermont Act 171's definition of a data broker -- that is outside the audit scope. Companies with SOC 2 reports feel credibly compliant in a general sense and do not scrutinize state-specific regulatory obligations with the same rigor. The gap between security compliance posture and regulatory registration status is wide enough that at least one enforcement case will expose it publicly.
Confidence: mediumA publicly reported AG enforcement action against a SOC 2-certified unregistered data broker, with the certification status noted as a contributing factor in the company's misplaced compliance confidence, before Q4 2027.
The registration requirement is doing more regulatory work than the security requirement
This is a stated opinion. Vermont Act 171's most consequential provision is not the reasonable security requirement -- it is the registration and disclosure requirement. Registration creates a public record of data broker activity. That record enables enforcement, enables consumer awareness, and enables legislative assessment of whether the broker ecosystem is operating as intended. The security requirement is important but it is also vague, contested, and subject to significant interpretation. A broker can argue about what 'reasonable' security means for years. It cannot argue about whether it registered. The organizations most exposed under Act 171 are not the ones with the weakest security programs. They are the ones that have not registered because they misclassified their activities and have years of unregistered data broker operation as the consequence.
Counterargument
The strongest counterargument is that security failures produce the actual harm -- exposed consumer data, re-identified opted-out individuals, breached behavioral profiles -- while registration failures are administrative. Under that view, enforcement resources should concentrate on security failures because the consequences are more concrete. That argument would be more persuasive if the AG's enforcement mechanism worked that way. It does not. The AG can act on registration failures without demonstrating harm. Security failures require a breach or a specific victim complaint to trigger investigation. Registration status is auditable from a public database. The administrative violation is actually the easier enforcement case.
One check worth running before the January 31 registration deadline
Pull the list of every third party your organization sold or licensed consumer data to in the last 12 months -- not the list in the privacy policy, but the actual commercial agreements and data transfer records. For each recipient, determine whether the Vermont residents whose data was involved had a direct relationship with your organization or with the recipient. If the answer is no for any recipient and your organization was not registered as a Vermont data broker for that period, the exposure is already established. The registration deadline is January 31 each year. Missing it is not a correctable oversight -- it is a documented period of unregistered operation. If the answer is yes you should have been registered, register now and document the circumstances. That is a better evidentiary position than continuing unregistered.
Further Reading
NIST
NIST security frameworksISO
ISO security controlsVulnox Service
compliance gap analysisUS state privacy and data security laws: the complete compliance map
Vermont Act 171 compliance requirements for data brokers operating without a direct consumer relationshipNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkHIPAA Official Homepage
HIPAA regulatory overviewCISA Known Exploited Vulnerabilities
CISA vulnerability catalog
Frequently Asked Questions
Does my company need to register under Vermont Act 171 if we sell audience segments, not raw data?
Potentially yes. Vermont Act 171 registration is triggered by selling or licensing personal information of Vermont residents to third parties without a direct consumer relationship. Audience segments derived from personal information remain personal information if the data can be linked back to individuals -- which targeted advertising segments are designed to do. The product framing as 'analytics' or 'insights' does not change the underlying data's regulatory status. SOC 2 certification does not assess or resolve this question.
What opt-out documentation does the Vermont AG require during an investigation?
Enforcement practice indicates the AG expects a timestamped record of each opt-out request received, documentation of identity verification, confirmation of data removal from active processing systems, and a consumer confirmation record. A CRM ticketing system with free-text notes does not meet this standard if it cannot export a structured, timestamped audit log for a specific consumer on a specific date. The evidence standard is about reconstructing what happened for an individual request, not about demonstrating that a process exists.
Does PCI DSS compliance satisfy Vermont Act 171 reasonable security requirements?
No. PCI DSS scope covers the payment card data environment. Vermont Act 171 Section 9403(a) reasonable security applies to all personal information the data broker holds -- names, addresses, email addresses, purchase histories, behavioral data stored outside the payment environment. A company can be fully PCI DSS compliant and simultaneously fail Act 171's security requirement for the consumer data outside PCI scope.
What happens to opted-out consumer data in backup systems?
Vermont Act 171 does not explicitly address backup and archival copies after an opt-out request. In practice, most organizations configure opt-out to remove data from active production systems only. Backup tapes, snapshot archives, and data warehouse historical partitions retain the opted-out data. The AG's enforcement position on archival copies has not been formally tested, but the gap creates re-identification risk in any backup system breach and is likely to be addressed in future enforcement guidance.
What are the penalties for failing to register as a Vermont data broker?
Vermont Act 171 authorizes the AG to seek civil penalties of up to $10,000 per violation. Operating as an unregistered data broker constitutes a violation for each year of unregistered operation, not a single violation. The AG can also seek injunctive relief and attorney's fees. The registration deadline is January 31 of each year.
Does using an enterprise platform like Salesforce satisfy Vermont Act 171 security requirements?
No. Platform certifications -- SOC 2, ISO 27001 -- cover the vendor's infrastructure controls. They do not cover the customer's configuration of that platform. Default Salesforce configurations do not enable field-level encryption, apply least-privilege access profiles, or configure audit logging for regulatory compliance. Act 171's reasonable security requirement applies to the actual data handling environment, which includes how the customer has configured the platform, not just whether the platform vendor holds certifications.
How does Vermont Act 171 define a data broker?
A data broker under Act 171 is any business that knowingly collects and sells or licenses to third parties the personal information of Vermont residents with whom the business does not have a direct relationship. The definition turns on the commercial transaction structure -- specifically, whether the buyer of the data has a direct relationship with the individuals whose data is being sold. Exclusions exist for consumer reporting agencies under FCRA, financial institutions under GLBA, and covered entities under HIPAA, but these exclusions are narrower than most compliance teams assume.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.