It's 7:15 on a Friday evening. A staff member texts your executive director: something is wrong with her laptop. Files she didn't open are showing as accessed. Your IT contact (a part-time consultant) isn't picking up. The director is at a community event and won't be back until morning.
Under your City of LA contract, the clock is already running.
PSC-22, the new Personal Services Contract provision now in effect for LA City contractors, requires you to notify the City within 24 hours of discovering a data breach. Not 24 business hours. Not within a reasonable timeframe. Twenty-four hours from the moment you discover an incident.
For most nonprofits running lean, that window is far smaller than it sounds.
This article breaks down what the requirement means, what counts as a breach, why most small organizations aren't ready for this, and what you can do right now, before an incident forces the question.
What PSC-22 Actually Requires
PSC-22 establishes a set of cybersecurity and data protection obligations for contractors working with the City of LA. The breach notification requirement is one of the most operationally demanding provisions in the update. Not because it's technically complex, but because it demands an immediate, coordinated response from an organization that may never have thought through what that looks like.
The requirement is clear: if you experience a data breach or unauthorized access to City data, you must notify the appropriate City contact within 24 hours of discovery.
That means your organization needs to know:
- Who internally is responsible for identifying a potential breach
- Who has the authority to make the notification decision
- What the City's notification contact information is
- What information the notification must include
Most City contractors can answer none of those questions right now. That's the real problem.
What Counts as a Breach
You don't need a ransomware attack or a headline-grabbing hack for this requirement to apply. Under PSC-22, a breach includes any unauthorized access to, acquisition of, disclosure of, or destruction of City data or systems, including personal information about the clients you serve.
In practical terms for a small nonprofit, that includes:
- A stolen or lost device containing unencrypted case files
- A staff member's email account being compromised through phishing
- Unauthorized access to a shared drive or cloud storage folder
- An accidental disclosure of protected client information to the wrong recipient
- A software vulnerability that allowed data to be accessed without authorization
You don't need certainty that data was taken. If there's reasonable cause to believe that unauthorized access occurred, the notification requirement is triggered.
This is a critical point. Many organizations wait to report because they're still "investigating." But the 24-hour window starts at discovery, not at conclusion. Waiting for certainty while the clock runs is one of the most common ways organizations find themselves in violation.
Why Most Small Nonprofits Are Not Ready
The City's own language in rolling out these requirements acknowledged the reality: new compliance obligations represent "a heavy lift for some of our community-based nonprofits." That framing is honest, and it reflects what we see regularly.
Most small nonprofits managing City contracts operate with:
No designated incident response contact
When something goes wrong, the question of who handles it is answered on the fly. That works when the stakes are low. It doesn't work when you have 24 hours and a contract on the line.
No documented escalation procedure
Even organizations with some IT support rarely have a written process that staff can follow independently. That matters when the incident happens at 7pm on a Friday and the IT consultant isn't answering.
No data inventory
You can't notify the City of what was accessed if you don't have a clear picture of what data you hold, where it lives, and who has access to it. Many nonprofits have client data spread across shared drives, personal email accounts, and case management software with inconsistent access controls.
No record of who to notify
The notification has to go somewhere. Do you know who your City contract liaison is? Do you have their contact information accessible outside your work email, which may itself be compromised?
These aren't failures of intent. They're predictable gaps in organizations that have been focused on delivering services, not building compliance infrastructure. But the contract doesn't distinguish between the two.
What Happens If You Miss the Window
This is where the stakes become concrete.
PSC-8, the contract modification that accompanies PSC-22, establishes immediate contract termination as a defined consequence of a data breach combined with failure to meet notification obligations. Not a warning. Not a remediation period. Termination.
For a small nonprofit, that consequence chain looks like this:
- Contract terminated mid-program year
- City funding stops
- Client services are disrupted
- Staff positions are put at risk
- The organization's reputation in the community takes damage that may take years to repair
It's also worth noting that unauthorized use of AI systems, covered separately under PSC-23, carries the same termination risk. The City is drawing a clear line: compliance is a contractual obligation, not a recommendation.
The organizations most at risk aren't the ones ignoring these requirements. They're the ones who simply haven't built the infrastructure to meet them yet.
What You Can Do This Week
The goal isn't perfection. Auditors and oversight bodies respond to documented, consistent, good-faith compliance efforts. Here's a realistic first-step action plan for the next five to seven days.
1. Name your incident response contact
This is a person, not a department. It should be someone with authority to make decisions and the ability to be reached outside of business hours. Write their name and contact information down somewhere accessible to your leadership team.
2. Draft a one-page escalation procedure
It doesn't need to be a complex document. It needs to answer four questions: Who identifies a potential breach? Who decides whether it triggers notification? Who notifies the City? What information goes in the notification? A one-page document that answers those questions is more valuable than a 40-page policy no one has read.
3. Locate your City contract contact information
Find the name and contact details for your contract liaison or the appropriate City department. Store it somewhere you can access it quickly, including if your email is the thing that's been compromised.
4. Start a basic data inventory
List the categories of data you hold under your City contract (client names, case information, financial records, health data) and where that data is stored. You don't need a full audit. You need enough to know what you'd be reporting on if something goes wrong.
5. Check what devices have access to City data
Personal laptops, shared office computers, staff phones: if they can access files or systems that contain City data, they're part of your breach exposure. Knowing the scope of that access is the foundation for everything else.
The Bottom Line
The 24-hour notification requirement isn't a future concern. It's already in your contract. And the gap between where most nonprofits are today and where they need to be isn't technical. It's structural. It's the absence of a plan, a named contact, and a documented procedure.
That's fixable. But it needs to happen before an incident, not during one.
The organizations most at risk aren't the ones ignoring these requirements. They're the ones who simply haven't built the infrastructure to meet them yet.