State privacy laws now require risk assessments. Most of the documents we review would not survive a regulator reading them.
Virginia, Colorado, Connecticut, and most of the state privacy laws that followed require documented data protection assessments for higher-risk processing, and California's regulations add risk assessment requirements of their own. A real assessment describes the processing, weighs it honestly against the risk to the people involved, and states the safeguards. The weighing is where most fall down, because it is the part that can conclude you should not do it.
- Assess firstA design control, not a filing exercise
- State lawsVA, CO, CT and the laws that followed
- CCPA/CPRACalifornia risk assessment rules phasing in
- On requestRegulators can demand the document
Six things deciding whether an assessment would survive being examined.
The trigger is heightened risk, not a category of data
Under the state laws the duty attaches to processing presenting a heightened risk of harm to consumers. Under GDPR the trigger is processing likely to result in a high risk to somebody rights and freedoms, particularly where new technology is involved. Both frame the question around consequences for people rather than around whether the data feels sensitive, which is exactly why novel technology attracts the requirement even when the data itself is entirely ordinary.
The named cases map to what US companies are deploying now
The state statutes name targeted advertising, the sale of personal data, sensitive data processing, and profiling that presents certain foreseeable risks. GDPR names systematic automated evaluation with legal or similarly significant effects, large-scale special category processing, and systematic monitoring of publicly accessible areas. Between them: ad tech, scoring models, biometrics, and camera analytics are squarely in scope.
A systematic description of the processing and its purposes
The first thing required: what data, about which people, for what purpose, on what legal footing, accessible to whom, and kept how long. In practice companies complete this section adequately, because it only requires describing things. It is also the section that most often reveals nobody had ever written down precisely what the system does with personal data.
The weighing, which is the difficult part
The state laws require weighing the benefit of the processing against the potential risk to the consumer, allowing for whatever safeguards exist. GDPR requires assessing whether the processing is necessary and proportionate. This is the section most often reduced to a single sentence, because answering it honestly can conclude that something less intrusive would achieve exactly the same purpose, which is an uncomfortable thing to write about a project already funded and running.
Risk to the people, not risk to the organization
The question here is what could happen to the people whose data is being processed. That is a genuinely different exercise from a security risk assessment, which asks what the company stands to lose. Both are legitimate exercises. Substituting one for the other is the most common structural defect across every assessment we review.
Safeguards stated specifically, because a regulator can read this
The measures that address the risks, stated as named controls with owners: access restriction, retention limits, de-identification, monitoring, contractual terms with processors. State attorneys general and regulators can require production of the assessment, so a general commitment to appropriate measures is a restatement of the obligation rather than a response to it.
The weighing is a required content, and it can conclude no.
Of everything the assessment must contain, this is the part most often reduced to a sentence, and it is the part that makes the assessment a control rather than a record.
- The requirement is a genuine weighing: the benefits of the processing against the risks to the people involved, offset by safeguards. Not a statement that the processing is justified, an assessment of whether it is.
- A real assessment asks whether the purpose could be served with less data, with that data held for a shorter period, with aggregation or de-identification instead of identifying anybody, or without the processing happening at all. Occasionally the answer is that it could, and that is precisely why the assessment belongs before the system gets built rather than after.
- That is deeply uncomfortable once a project is funded and running, which is exactly why this belongs at the design stage rather than as a compliance box ticked the week before launch. At design stage a finding is simply a change. The week before launch it is a delay.
- It is also the section a state attorney general or regulator will look at hardest if the assessment is ever produced on request, because the description tells them what you do and the weighing tells them whether you thought about it.
Four things that make an assessment a control rather than a record.
We answer the weighing question properly, and early
Could the purpose be achieved with less data, shorter retention, or without identifying people. That question has a real answer, and at design stage the answer is a design change. Before go-live it is a delay, and after go-live it is a finding somebody has to explain. The timing determines the cost of every conclusion.
We assess risk to the people, not to the organization
A privacy assessment asks what could happen to the individuals whose data this is. An information security risk assessment asks what the organization could lose. Both are legitimate and they are different exercises. Substituting the second for the first is the most common structural defect in the assessments we review.
We write specific safeguards with owners, not general commitments
Retention configured and enforced, access restricted and reviewed, de-identification applied where the purpose allows it, processor terms verified. Named controls with named owners and dates are what a regulator can verify later, and they are also the part we can implement, because the safeguards live in your systems.
We work alongside your counsel, not instead of them
We are an IT services firm, not a law firm. Your privacy counsel or officer owns the legal interpretation of which state obligations bind you and how. We own the operational side: mapping where the data actually lives, running the technical assessment honestly, and building the safeguards into Microsoft 365, your cloud platforms, and your retention configuration so the document describes something real.
Six US situations where an assessment is required or clearly advisable.
A business deploying a model that makes decisions about people
Profiling that presents foreseeable risks to consumers is a named trigger in the state statutes, and automated evaluation with legal or similarly significant effects is a named GDPR case. Screening, scoring, eligibility, and prioritization systems all fall here, and increasingly so does anything with a model in the decision path.
A company running targeted advertising or sharing data with ad platforms
Targeted advertising and the sale or sharing of personal data are the most commonly triggered categories in the state laws, and the definitions are broader than most marketing teams assume. The assessment is where pixel inventories, audience building, and data-sharing arrangements get documented and weighed before an enforcement letter asks about them.
A healthcare or wellness organization processing health data
Sensitive data is a trigger category, and health data held outside HIPAA-covered relationships, in wellness apps, employer programs, and analytics, is exactly where state privacy law reaches. The assessment establishes what is collected, why, and under what safeguards, before a regulator or plaintiff asks the same questions.
An employer introducing workplace monitoring
Monitoring tools, productivity analytics, and camera systems process employee personal data systematically. An assessment run before deployment is where the retention period, the access model, and the proportionality question get decided rather than assumed, and it is the difference between a defensible program and an industrial relations problem.
A business deploying biometric access or identification
Biometric data is sensitive data under the state statutes, and biometric privacy statutes in states like Illinois carry private rights of action that have produced very expensive litigation. The weighing question is particularly pointed here, because a card or a credential usually achieves the same access control purpose with far less exposure.
A firm launching a product that uses customer data in a new way
A new product or AI feature that uses existing customer data for a purpose customers would not expect meets the heightened-risk framing regardless of whether the data itself is sensitive. The assessment belongs in the product design, where its findings are changes rather than delays.
How US organizations handle privacy assessments.
| Feature | Assessment at design stage | A template completed before go-live | No assessment |
|---|---|---|---|
Processing described systematically | Yes | Yes | No |
Benefits genuinely weighed against risks | Yes | Rarely | No |
Less intrusive alternatives considered | Yes | No | No |
Risk assessed to people, not the organization | Yes | Sometimes | No |
Safeguards specific with owners | Yes | Generic | No |
Residual risk accepted by a named person | Yes | No | No |
Privacy counsel or officer involved | Yes | Sometimes | No |
Producible to a regulator on request | Yes | Awkwardly | No |
Has ever changed a design | Yes | No | Not applicable |
Cost of a finding | A design change | A delay | An enforcement letter |
The common triggers, and what they look like in practice.
Trigger
Targeted advertising
- What it looks like in practice
- Ad tech pixels, audience building, and cross-context behavioral advertising on your own properties
Trigger
Sale or sharing of personal data
- What it looks like in practice
- Data passed to partners, brokers, or platforms in exchange for anything of value, which is broader than cash
Trigger
Sensitive data processing
- What it looks like in practice
- Health data, biometrics, precise geolocation, immigration status, and data about children
Trigger
Profiling with significant effects
- What it looks like in practice
- Credit and eligibility decisions, automated screening, scoring models, and increasingly anything at all with a model sitting somewhere in the decision path
Trigger
Systematic monitoring
- What it looks like in practice
- Camera systems across sites, footfall analytics, workplace monitoring, and vehicle recognition
Trigger
New technology on existing data
- What it looks like in practice
- A new product or AI feature that uses customer data in a way customers would not expect
Five steps, and the earlier it starts the cheaper every finding is.
- 1
Confirm which obligations apply, with your counsel
Which state laws reach you based on where your consumers are and what you process, whether California's risk assessment regulations apply, and whether GDPR reaches you through EU personal data. That answer, confirmed rather than assumed, determines whether the assessment is mandatory, advisable, or unnecessary.
- 2
Describe the processing systematically
The categories of data, the people involved, the purposes, everybody with access including processors and platforms, the retention and the reason for it, and where the data physically sits across your Microsoft 365 tenant, cloud platforms, and SaaS estate. This is descriptive work and it frequently produces the first surprise.
- 3
Weigh the processing honestly
Could the purpose be achieved with less data, a shorter retention, aggregation instead of identification, or not at all. The least intrusive alternative has to be considered in order to be rejected. This is the section that makes the assessment a control, and it is run with the people who own the project rather than about them.
- 4
Assess risk to the individuals and design the safeguards
What could happen to the people whose data this is, stated concretely rather than as a category. Then the safeguards that address those risks, each specific, each with an owner and a date, and each actually implemented in the systems rather than described in the document.
- 5
Record acceptance and keep it live
Residual risk accepted by a named person with the authority to accept it, the document filed where it can be produced if a regulator requests it, and a review trigger built into your change process, because an assessment describes a system as designed and systems change.
What US organizations ask about privacy impact assessments.
Fifteen questions the assessment has to answer.
Describing the processing
- What data, about whom, and how much?Specific categories, not personal data generally.
- What is the purpose, precisely?A vague purpose cannot be tested.
- Is any of it sensitive data?A trigger category in its own right.
- Who has access, including processors?Vendors, platforms, and anybody offshore.
- How long is it kept, and why?Retention is part of the description.
The weighing
- Could the purpose be met with less data?The core question.
- Could it be met with a shorter retention?Frequently yes.
- Could it be met without identifying people?Aggregation or de-identification.
- Is the benefit specific enough to weigh?State the benefit concretely.
- What is the least intrusive alternative?It has to be considered to be rejected.
Risk and safeguards
- What is the risk to the people involved?Not to the organization.
- What would the worst outcome be for them?Stated concretely.
- What specific safeguards reduce that risk?With owners and dates.
- What residual risk remains?And who accepted it.
- Would this survive a regulator reading it?Assessments can be demanded on request.
Read the weighing section of your last assessment. If it is one sentence, that is the finding.
It is a required content and it is the one that can change a design. An assessment where it has been reduced to an assertion has recorded a decision rather than tested one, which is a difference a regulator will notice.
Related Services
Explore more solutions that work great with this service
IT Compliance
HIPAA, SOC 2, NIST, CMMC, CCPA readiness
Learn moreMicrosoft Purview
Data governance and compliance solutions
Learn moreAccess Rights Review and Certification
Recurring access certification your auditors accept
Learn moreSOC 2 Readiness
Get audit-ready for the report your buyers ask for
Learn more