Profiling and Automated Decision-Making Checklist for Founders and Compliance Leads

Profiling and automated decision-making are checklist-ready when a SaaS team can show which systems evaluate people, which outputs influence decisions, who owns the review, what safeguards exist, and where the evidence lives. The checklist is not only for legal interpretation. It is a practical control for product planning, vendor intake, AI review, customer due diligence, and audit readiness.

Under the GDPR, profiling is automated processing of personal data used to evaluate personal aspects of a person. Article 22 is narrower: it focuses on decisions based solely on automated processing, including profiling, where those decisions produce legal effects or similarly significant effects. That means a SaaS team should not treat every score as the same risk, but it also should not ignore scoring just because a human is somewhere nearby.

Use this checklist before launching a new workflow, buying a vendor tool, adding an AI feature, changing a threshold, reusing a score, or answering a customer question about how automated outputs affect users.

For founders and compliance leads, the checklist also creates a shared language with engineering, security, sales, support, and customer success. Without that shared language, teams either over-escalate every automated output or miss the few workflows that genuinely need deeper review.

1. Inventory the Workflows

Start by listing every workflow that scores, ranks, predicts, flags, recommends, approves, rejects, suspends, routes, prioritises, or prices an individual. Include customer-facing product features, internal dashboards, support tooling, CRM scoring, fraud detection, identity checks, security alerts, customer success health scores, moderation systems, workplace analytics, advertising tools, and AI copilots.

For each workflow, record the system name, owner, purpose, data subjects, personal data used, output produced, users of the output, and where the decision or recommendation appears. Link to product tickets, architecture notes, vendor documents, model descriptions, rule logic, data maps, and support playbooks.

Do not rely on vendor labels. A vendor may call something an insight, recommendation, quality score, risk signal, eligibility factor, or prioritisation rule. The compliance question is what it does with personal data and how people are affected.

The inventory should also include internal reuse. A score built for support prioritisation can later appear in customer success segmentation, fraud review, account enforcement, or sales routing. Reuse is often where the risk changes, because the original review may not have considered the new consequence for the individual.

2. Classify the Decision Type

Classify each workflow into one of four practical buckets.

Ordinary automation does not evaluate personal aspects of a person. Examples include sending a renewal reminder based on contract date or routing a generic ticket by language.

Profiling uses personal data to evaluate or predict something about a person. Examples include churn likelihood, fraud risk, trust score, lead score, health segment, behavioural segment, employee productivity signal, or likelihood of policy violation.

Automated decision support gives a human an output that may influence a decision. The human role must be real, informed, and capable of changing the outcome if the team wants to rely on that review.

Solely automated significant decisions are the highest-risk bucket. These include automated decisions that may deny, suspend, terminate, materially restrict, price, rank, or approve a person in a way that creates legal or similarly significant effects.

Record the classification and the rationale. Also record what would change the classification, such as a score being reused for enforcement, pricing, eligibility, account access, employment, credit-like decisions, or safety.

This classification gives executives a cleaner decision point. They do not need every technical detail to see whether the workflow is routine, needs privacy controls, needs cross-functional review, or should pause until the design changes.

3. Confirm Lawful Basis and Scope

For each profiling or decision workflow, confirm the lawful basis for processing. Also check whether the workflow involves special category data, children, employees, vulnerable people, biometric data, location data, financial data, health-related data, or large-scale monitoring.

If Article 22 may apply, confirm whether the decision is necessary for a contract, authorised by law, or based on explicit consent, and whether the required safeguards are available. If none of those routes fits, the workflow should not proceed in that form.

This is also the point to check controller and processor roles. A SaaS vendor may be a processor for customer-configured scoring but a controller for its own abuse prevention, telemetry, product analytics, or account-risk processing. Mixing those roles creates confused notices, weak contractual promises, and poor evidence.

If the company sells into regulated customers, document the role analysis in a way sales and customer trust teams can reuse. Enterprise buyers often ask whether automated scoring affects their users, whether the vendor trains models on customer data, and whether the customer can configure or disable the workflow.

4. Define the Owner and Review Path

Every workflow needs one accountable owner. That owner does not need to answer every legal, security, or data science question alone. Their job is to keep the review moving, collect evidence, route issues, record decisions, and trigger refreshes.

Define the review path by risk level. Low-risk profiling may need a short privacy screen and standard controls. Medium-risk workflows may need transparency updates, vendor review, data quality checks, support routing, and monitoring. High-risk profiling and solely automated significant decisions may need legal review, DPIA consideration, fairness testing, stronger human review, and formal risk acceptance.

The workflow should make clear who can approve launch, who can block launch, who owns mitigations, and who reviews the workflow after changes.

This matters during audits because reviewers usually ask who was responsible, not only whether a policy existed. A named owner, dated decision, mitigation list, and review trigger are much stronger than a generic statement that the privacy team was consulted.

5. Design User-Facing Transparency

Users should not discover profiling only after a negative outcome. Decide what needs to appear in the privacy notice, product copy, account status messages, appeal flows, customer documentation, and support scripts.

Where required, explain the purpose, data categories, broad logic, significance, and expected consequences in language that a non-specialist can understand. Avoid fake transparency. A vague sentence saying that the company uses automated tools for service improvement will not help users understand a workflow that affects access, eligibility, enforcement, pricing, or important treatment.

If the system affects a customer's end users, give customers the operational information they need to meet their own transparency duties.

For product teams, this is easier when transparency is designed alongside the feature. Waiting until launch often leaves the team with only broad legal copy, while the product still lacks status messages, appeal prompts, or explanations that make sense in the actual user journey.

6. Build Rights and Contest Routes

People may ask what data was used, challenge accuracy, object to processing, request access, or contest an automated outcome. Support and privacy teams need a route before the first request arrives.

For Article 22 workflows, make sure the person can obtain human intervention, express their point of view, and contest the decision. The human reviewer must have enough context, training, authority, and time to change the outcome. A rubber-stamp approval does not make the decision meaningfully human.

Keep records of requests, reviews, overrides, outcomes, and response timing. These records are evidence that the safeguard is operational, not only promised.

Where a workflow can produce a negative outcome, define the minimum case file before launch. A good case file shows the input data, system output, reviewer notes, final decision, communication to the person, and any appeal or correction. That record makes later disputes far easier to handle.

7. Test Inputs, Outputs, and Fairness

Check the data feeding the score or decision. Old, inferred, proxy, incomplete, or free-text data can create unfair or inaccurate outcomes. Document which fields matter, why they are necessary, how they are updated, and how errors are corrected.

Testing should be proportionate to impact. A low-risk support queue score may need light monitoring and override paths. A workflow affecting access, employment, finance, education, housing, health, safety, enforcement, or essential services needs stronger testing, fairness review, and documented mitigation.

Track false positives, false negatives, override rates, complaint patterns, unusual group impacts, drift, threshold changes, and vendor updates.

Do not make testing purely technical. A model can perform well on aggregate metrics while still creating unacceptable operational outcomes, such as repeated false positives for a customer segment or escalation paths that support cannot realistically handle.

8. Review Vendors and AI Features

Vendor tools often introduce profiling quietly. Ask what personal data is used, what outputs are produced, whether scores or recommendations influence decisions, whether the vendor trains models on customer data, how model changes are communicated, and how access, deletion, objection, and contest requests are handled.

For AI features, ask what the system does to people. A summary that helps an agent read a support case is different from a model that labels a person risky, recommends suspension, predicts misconduct, ranks employees, changes eligibility, or routes enforcement.

Keep vendor questionnaires, contracts, subprocessors, model documentation, security reviews, and approval records linked to the workflow inventory.

If the vendor changes its model, training data policy, subprocessors, retention settings, or explanation features, the internal review may need to reopen. Put that obligation into vendor management instead of depending on someone remembering it later.

9. Preserve Evidence

The strongest evidence is a connected record: trigger screen, classification, lawful basis, data inputs, owner, review path, safeguards, transparency update, rights route, vendor review, test results, approval, monitoring plan, and refresh trigger.

Founders and compliance leads should be able to answer three questions quickly: what does the system do, how can it affect a person, and what proof shows the company reviewed and controlled it?

This evidence is especially useful in customer due diligence. A clear workflow record lets the team answer security questionnaires and legal reviews without rebuilding the story from Slack threads, product tickets, and vendor emails.

10. Refresh the Checklist

Refresh the review when model logic, thresholds, data sources, vendors, markets, user groups, product use, human review practice, or customer commitments change. Also refresh when complaints, appeals, false positives, incidents, or regulatory guidance reveal a new risk.

The checklist should live close to product and vendor workflows. If it only exists in a compliance folder, teams will find it after the decision has already shipped.

FAQ

What should teams understand about profiling and automated decision-making?

Teams should understand whether the workflow evaluates people, whether it influences meaningful decisions, what controls apply, and what evidence proves the review was completed.

Why does profiling and automated decision-making matter in practice?

It shapes product design, vendor selection, customer trust, user rights, audit evidence, and the ability to explain decisions when something goes wrong.

What is the biggest mistake teams make?

The biggest mistake is treating profiling as a one-time legal interpretation instead of a repeatable workflow with owners, triggers, safeguards, evidence, and refresh points.

Sources

This checklist relies on the GDPR, EDPB-endorsed WP29 guidance on automated individual decision-making and profiling, and ICO guidance on automated decision-making and profiling.