Oregon nonprofits sit under a privacy law that most nonprofits in this country don’t.

The Oregon Consumer Privacy Act covers qualifying nonprofits, which makes Oregon unusual. It’s also the only state that includes crime victim status and transgender or nonbinary status in its definition of sensitive data.

Read that second sentence again if your organization serves survivors, houses people, or works with youth. The information carrying the most legal weight in Oregon isn’t your donor list. It’s what you hold about the people you serve.

And most of it doesn’t live on equipment you own. It lives in platforms other companies run for you, configured by people you’ll never meet, secured according to judgment you never see.

Which brings me to a support ticket I still think about.

The recommendation

Years ago I was the IT director for a large nonprofit. We ran our volunteer database and the volunteer-facing website on a third-party platform. The vendor hosted it on AWS.

The vendor rotated the site’s IP address roughly every two weeks.

So every two weeks the site stopped loading. Our program manager, who owned the vendor relationship, would call the vendor, get the new address, and open a ticket with IT to allow it. IT would make the change. The site would come back. Two weeks later it happened again.

The platform came in with an acquisition around the time I started. That loop had been running for about a year before it reached me.

Not because anyone hid it. Because it worked. A process that resolves every ticket generates no signal. Every step was somebody doing their job, and none of it required a director.

Eventually the program manager got tired of opening the same ticket every two weeks and asked the vendor for a permanent fix.

Their answer was to allow every IP range in AWS.

So she submitted a ticket asking us to do exactly that. My IT staff read it, recognized what was being requested, and brought it to me instead of implementing it.

That’s the only reason I found out.

She did the right thing. She recognized a recurring problem and went to the vendor for a real solution. What she couldn’t do is evaluate whether the answer she got back was safe, because that isn’t her job. It’s the answer that was the problem, not the question.

Opening your network to all of AWS doesn’t let your vendor in. It lets in anyone renting a server from AWS, which is anyone with a credit card. In your firewall it looks like a narrow exception. In practice it’s an open door.

So I asked them for a static IP address instead.

They said they couldn’t do that.

I pushed back, and eventually they assigned a static IP to our site.

I never found out why the first answer was no. Maybe nobody on that support tier knew the option existed. Maybe a dedicated address carried a cost the vendor didn’t want to absorb. Maybe both.

It doesn’t matter much, and that’s the point. I couldn’t see inside their decision, and I still had to make mine.

What I do know is that the capability existed, and that the answer their support gave first went out to every customer who asked the same question. So how many other nonprofits opened ports, or opened their networks to every IP range in AWS, because the company they were paying told them there was no other way?

Why this beats a breach story

Nothing was breached. No data left. No incident report, no notification letter, no lawsuit.

That’s exactly why I tell it.

Breach stories let you off the hook. You read about an organization that got hit, note what they did wrong, conclude you’re different. The failure looks dramatic and rare.

What actually happens is quieter. The process caught the anomaly and never caught the pattern. Twenty-something routine tickets over a year, every one individually legitimate, none of them worth escalating. Then one abnormal request, flagged immediately. Ticket queues are built to notice what looks wrong, not what keeps happening.

If the vendor had just kept handing out new addresses, that loop would still be running and I still wouldn’t know about it.

And volunteer records are personal information. Names, contact details, sometimes background check results. Oregon’s breach notification law reaches personal information held in the course of a person’s business, vocation, occupation, or volunteer activities. Volunteer data was never outside the scope.

It happens here

If you want to know whether this is a real problem in Oregon rather than a hypothetical one, the state publishes the answer.

The Oregon Department of Justice maintains a public list of organizations that sent breach notices to the Attorney General. You can read it. Oregon organizations are on it by name. One line on that page is worth more than the whole list. DOJ notes that in some cases the organization sending the notice is not the one that experienced the breach.

That’s the vendor scenario, described by the state, on the page where your name would go.

The scale of it isn’t new either. Blackbaud, a fundraising platform used across the nonprofit sector, was hit by ransomware in 2020. The October 2023 multistate settlement came to $49.5 million and required seven years of third-party compliance assessments. In a separate action, the FTC required comprehensive security improvements and ordered Blackbaud to stop misrepresenting its security practices. The FTC described the vendor’s pre-breach security as shoddy.

It’s still happening. This month a CRM provider serving over a thousand charities confirmed an attacker copied its entire customer database, including attachment files, after a compromised AWS access key was exposed in publicly accessible JavaScript build artifacts.

What the vendor can’t do for you

When a provider calls to say your data may have been taken, here’s the questions you need to ask. 

What did we actually put in that platform? Not what we bought it for. What ended up in it after four years of staff using it. Did anyone upload attachments, case notes, intake documents? Which donors, volunteers, members or clients are in scope? Do we call counsel or our insurance broker first? Does Oregon law require notification here? What do we tell the board, and when? Who talks to the people who trusted us?

Your vendor cannot answer a single one of those, the good ones say so directly. The CRM provider in that August breach told its customers to conduct their own risk assessments and determine whether affected individuals required notification, based on the personal and sensitive data each organization had stored in the platform.

That’s a vendor saying, correctly, that the assessment and the notification decision belong to the customer.

Meanwhile a clock is running. ORS 646A.604 requires notice to affected consumers in the most expeditious manner possible, without unreasonable delay, and no later than 45 days after discovering or receiving notification of a breach. It starts when the vendor calls you, not when you finish figuring out what happened. If more than 250 Oregon consumers are affected, a report and a sample copy of the consumer notice also go to the Oregon DOJ inside that same 45 days.

There’s a piece people miss. Notice isn’t required if, after appropriate investigation, the organization reasonably determines affected residents are unlikely to suffer harm. That determination is only available to an organization that knows what it had in the platform. If you can’t establish that, you can’t make the finding, and the exemption isn’t there for you. Your counsel makes the call on your specific facts. My point is narrower. The quality of the legal advice you can get depends on how fast you can say what was in there.

The platform you approved isn’t the platform you have

My volunteer database is a small version of a bigger pattern.

A nonprofit buys a CRM to track donor contact information. Then it gets used. Donation histories accumulate. Volunteer records go in. Membership status, event attendance, correspondence, notes from staff about a family they’re serving, documents scanned and attached because that was the easiest place to put them. Integrations get built to the payment processor, the email platform, the fundraising tools.

None of that requires a leadership decision. It happens because the platform is useful and people use it.

The same way a two-week firewall exception becomes a standing operating procedure. Nobody decided. It accrued.

And some of it you inherit. A merger, a program transfer, a department that brought its own tool. Those arrive with configurations nobody currently in the building chose, and no onboarding process includes auditing them.

So exposure grows while the organization’s understanding of the vendor stays frozen at whatever it was the day the contract was signed.

Four assumptions worth checking

1. Security is the vendor’s job. The exposure in my story wasn’t the vendor’s uptime or their breach history. It was the quality of the advice their support gave about their own platform. You can outsource the system. You can’t outsource whether the guidance about it is any good.
2. Our data is encrypted. Encryption at rest protects against a stolen disk. It does nothing against a stolen credential, over-permissioned access, or an export that looks legitimate to the system performing it. In that August breach the data was encrypted at rest, and the attacker authenticated with a valid access key, so it decrypted normally for what appeared to be an authorized session.
3. The contract covers this. A contract can obligate a vendor to notify you. It cannot make your legal determination, your insurance notification, your communications decisions, or your board conversation.
4. IT will catch what looks wrong. My staff flagged the dangerous request immediately, which is why I’m telling this story instead of a worse one. What no ticket queue does is notice that the same exception has been requested twenty times, because each request was legitimate. Anomalies get escalated. Patterns don’t.