The conventional wisdom
Ask most DPOs how they manage processor risk and you'll hear a familiar sequence. Run a security questionnaire before onboarding, collect an ISO 27001 certificate or a SOC 2 report, sign a data processing agreement with Article 28 language, file it all, and repeat the exercise annually.
It's a reasonable model. Article 28(1) requires controllers to use only processors providing "sufficient guarantees" to implement appropriate technical and organizational measures, and documented due diligence is how you evidence that. Nobody should abandon it.
But the model rests on an assumption that deserves scrutiny: that a processor's declared posture at onboarding predicts its actual posture on a random Tuesday two years later.
Why that view is incomplete
A questionnaire is a snapshot of what the processor says about itself. It tells you nothing about the storage bucket someone provisioned last month, the staging database a developer spun up and forgot, or the backup repository created during a migration.
Consider what a recent exposure involving CitySourced, a service provider to local governments in the U.S., Canada, and the Caribbean, illustrates. A researcher, Jeremiah Fowler, found a publicly accessible database with no password protection or encryption. It held approximately 42 million records, with personally identifiable information stored in plaintext. Much of the content was images of code violation reports and complaints, some covering a decade of names, physical addresses, email addresses, and phone numbers. The repository also held top-level application directories and operational folders.
Notice what a point-in-time assessment could not have caught. A questionnaire answer like "we encrypt personal data at rest and enforce access controls" can be true at signing and false later. The failure here wasn't a missing policy. It was a gap between policy and configuration, and no annual paperwork cycle is built to detect that.
There's a second problem, specific to the public sector. The data in this kind of platform isn't a marketing list. Residents who report a code violation about a neighbor's property are submitting complaints they reasonably expect to stay confidential. Exposure in that context carries risks of retaliation and disputes between neighbors, on top of the usual identity-fraud concerns. Your risk rating for a processor should reflect what the data reveals, not just how much of it there is.
The evidence
Start with what the law actually asks of you. Article 28 isn't a one-time gate. It frames the processor relationship as ongoing: the contract must require the processor to make available all information necessary to demonstrate compliance and to allow for and contribute to audits (Article 28(3)(h)). Article 32 requires measures to include "a process for regularly testing, assessing and evaluating the effectiveness" of those measures (Article 32(1)(d)). The text anticipates continuous verification. Most processor programs deliver periodic attestation instead.
Then look at the incident mechanics. In this case, the database was restricted after the researcher notified the organization, and it's unknown how long the data had been accessible before that. That unknown is the whole problem. If the exposure window can't be established, the controller can't scope affected individuals, can't assess risk to them, and can't meet the Article 33 duty to notify the supervisory authority within 72 hours of becoming aware. Article 33(2) requires the processor to notify the controller "without undue delay," but that only helps if the processor knows. When discovery comes from an outside researcher, the clock effectively starts late for everyone.
Also consider who found it. The exposure surfaced through independent research, not through the processor's controls or the controller's oversight. Relying on strangers to audit your processors isn't a compliance strategy.
What to do instead
Keep the questionnaire. Stop treating it as the control.
Verify, don't just collect. Add external attack surface monitoring for your critical processors' internet-facing assets, within what your contract and applicable law permit. Publicly reachable, unauthenticated databases are exactly what this kind of scanning surfaces. Write the right to conduct or commission such checks into the Article 28 contract.
Tier by data sensitivity and exposure impact. A platform holding complaint submissions with contact details from residents belongs in your highest tier, whatever the processor's size. Review high-tier processors on a shorter cycle and ask for evidence of configuration management, not just policy documents.
Contract for speed. Set a specific processor-to-controller notification window shorter than the 72 hours you have yourself. Require the processor to preserve access logs so exposure windows can be reconstructed. Without logs, you can't answer the first question a supervisory authority will ask.
Minimize at the source. Plaintext storage of a decade of complaint history is a retention and Article 5(1)(c) minimization problem before it's a security problem. Ask processors what they keep, for how long, and why. Attachments and images often outlive any operational need.
Rehearse the processor scenario. For local governments and the DPOs advising them, the incident plan should cover the case where you learn of an exposure from a third party, with no processor alert. Who triages? Who contacts the processor? How do you establish scope without logs?
When the conventional wisdom is right
Due diligence still matters, and for good reasons. Article 28(1) makes it a legal requirement, and a supervisory authority will want to see it. Rigorous vetting also filters out processors with no security program at all, which is a real and common risk. Certifications like ISO 27001 do evidence that a management system exists, and a processor unwilling to provide one is telling you something.
For lower-risk processors handling limited, non-sensitive data, a proportionate questionnaire-and-contract approach is entirely defensible. Not every processor justifies continuous monitoring.
The argument isn't that paperwork is useless. It's that paperwork is the floor. For processors holding data on millions of people, your assurance should come from evidence that stays current, because an exposure can open and close between your annual reviews.
