Berkeley's mission-driven organisations are target-rich and defence-poor: they hold donor PII, payment data and information about vulnerable people, on budgets that rarely stretch to a security team. CyberFortify runs manual web, API, cloud and network penetration tests here, aligned to CCPA/CPRA, PCI DSS 4.0, SOC 2 and NIST CSF. Delivered remotely from our Gulf base on a daily overlap window, right-sized for a nonprofit budget. Fixed price, audit-ready reporting, free retest.
// 01 Why Berkeley organisations need penetration testing
Few cities pack as many nonprofits, foundations, research institutes and advocacy organisations into as small a footprint as Berkeley does. They run on trust and thin margins - the money goes to the mission, not to a security operations centre - and that is exactly the combination attackers look for. A group that holds ten thousand donor records and one part-time IT contractor is target-rich and defence-poor at the same time.
The data these organisations carry is more sensitive than their size suggests. Donor and constituent databases hold names, giving histories, payment details and, for many groups, information about the vulnerable communities they serve. Advocacy and human-rights organisations go further, holding records that could expose an activist or a beneficiary - which makes them targets not just of ordinary criminals but of hacktivists and, at times, state-aligned actors. The comfortable belief that "we are too small and too worthy to be attacked" is precisely the assumption those adversaries rely on.
A vulnerability scan will not surface the failures that matter here. It flags an unpatched library; it does not tell you that a supporter can change one number in a URL and read another donor's gift history, that a wire-change email would sail through unchecked, or that a Salesforce or Microsoft 365 tenant is sharing a beneficiary list far more widely than anyone intended. Those are authorisation and configuration decisions, and confirming them takes a tester, not a tool.
// 02 Compliance and regulatory drivers in Berkeley
Nonprofits are not automatically exempt from privacy law, and many process personal data at a scale that puts them squarely inside it. These are the requirements we most often map evidence against for Berkeley organisations.
CCPA / CPRA
Where your organisation meets the thresholds, California's consumer-privacy regime applies to donor and constituent data regardless of nonprofit status - rights of access and deletion, and duties to protect the information you hold.
Cybersecurity-audit & risk-assessment duties
The California Privacy Protection Agency's rules reach organisations processing personal information at scale. Many donor and beneficiary databases qualify, bringing risk-assessment and independent-testing expectations with them.
PCI DSS v4.0 - Req 11.4
Online donation pages, event ticketing and membership billing put you in scope for PCI DSS, and Requirement 11.4 expects penetration testing of the payment environment and proof of segmentation.
SOC 2
If your nonprofit is itself a service provider - a shared platform, a grant portal, a data intermediary - your partners will ask for a SOC 2 report, and independent testing is the evidence behind it.
Grant & partner security reviews
Grant funders and enterprise partners now send security questionnaires before releasing money or data. A recent penetration test is the cleanest way to answer the "have you been tested?" line honestly.
NIST CSF & CIS Controls IG1
You do not need an enterprise programme. NIST CSF and CIS Controls Implementation Group 1 give a defensible baseline scaled to a mission budget, and our testing evidences the controls that matter first.
// 03 Penetration testing services for Berkeley
Berkeley engagements weight the places donor and beneficiary data actually sits: the CRM and its authorisation logic, the cloud tenant that hosts everything, and the payment path behind the donate button. We scope to the risk, not to a checklist, so a small organisation pays for the tests that count.
Web application pen testing
Donor portals, membership sites, donation and event pages - tested against the OWASP Top 10, IDOR/BOLA on donor records, and business-logic abuse.
Cloud & SaaS pen testing
Microsoft 365, Google Workspace and Salesforce nonprofit configuration - identity, MFA gaps, over-sharing, mailbox rules and OAuth app grants that enable BEC.
API pen testing
The interfaces behind your CRM, fundraising platform and integrations - broken object-level authorisation, scope enforcement and token handling.
Network pen testing
External and internal testing plus Active Directory checks - credential stuffing, exposed services and the lateral paths an intruder would take.
Mobile app pen testing
Member, giving and field-worker apps - local data storage, certificate handling and the API traffic behind the screen.
Red teaming
For higher-risk advocacy groups - assumed-breach and data-exfiltration scenarios testing whether an intruder reaches beneficiary identities before detection.
// 04 How we deliver to Berkeley
We will not pretend otherwise: CyberFortify is a Gulf-based firm on UTC+3, and Berkeley sits ten to eleven hours behind us. We have no California office and no local staff. What we have is a working pattern built around that gap: our late afternoon and evening is your morning, and we hold that window open daily for stand-ups, live triage and read-outs - which matters more, not less, when the person on your side is a one-person IT team. Testing continues while Berkeley is offline, so results are waiting when your day starts.
What runs remotely
Web, cloud, SaaS, API and external testing from our secure environment - the large majority of nonprofit and advocacy scope. Findings land in a shared channel as confirmed, and anything that exposes donor or beneficiary data is escalated immediately.
What we do on-site
Internal network, wireless and segmentation testing where a tester genuinely needs to be on the wire, plus in-person briefings for boards and staff. We travel when it adds value and say so when it does not.
Every engagement opens with a free 30-minute scoping call and a fixed-price quote within the hour. We right-size the scope to what your budget and risk actually justify, and a free retest proves the fixes landed.
// 05 Organisations we secure in Berkeley
Berkeley's risk profile is shaped by an unusual density of mission-driven organisations, a strong research and philanthropic base, and the higher-risk advocacy groups that call the East Bay home.
// 06 Our methodology
Berkeley engagements follow the same audit-defensible process we run everywhere, tuned to the donor-data and targeted-threat reality of the sector. Testing is grounded in the PTES and NIST SP 800-115, with exploitation mapped to MITRE ATT&CK tactics and application work driven by OWASP, including the API Security Top 10. As a CREST Accreditation Pathway firm we lead with manual testing - automation supports the tester, never replaces one.
Scoping & rules of engagement
Targets, donor and beneficiary data boundaries, test accounts and escalation paths agreed in writing - and scope right-sized to your budget.
Fixed quote in 1hReconnaissance & threat modelling
Attack surface mapped around what an attacker wants: donor PII, payment flows, grant approvals, and - for advocacy groups - the records that identify a person.
ATT&CK alignedManual exploitation
Weaknesses are exploited and chained under controlled conditions - cross-donor access, BEC paths and SaaS over-sharing proven using seeded records, never live supporter or beneficiary data.
Controlled exploitReporting & free retest
Plain-language executive summary for the board, CVSS-scored detail for whoever fixes it, and mapping to CCPA/CPRA, PCI DSS, SOC 2 or NIST CSF - plus a free retest once fixes ship.
Audit-ready// 07 Why CyberFortify for Berkeley
A scan-and-report vendor
Automated output rebadged as a penetration test, priced for an enterprise, blind to authorisation logic - unable to tell whether one donor can read another's record or whether a wire-change email would be trusted.
CyberFortify
A Gulf-based, CREST-pathway team candid about the time difference and structured around it. Manual exploitation aimed at donor-data exposure, BEC and SaaS misconfiguration, scope right-sized to a mission budget, findings mapped to your funders' questionnaires, fixed pricing and a free retest.
Berkeley engagements most often pair a web application assessment with a cloud and SaaS penetration test, since donor data usually splits between the portal in front of it and the Microsoft 365 or Salesforce tenant underneath. For advocacy and human-rights organisations facing a targeted threat, we add red teaming to test whether an intruder reaches beneficiary identities before anyone notices.
// 08 Frequently asked questions
Can you test our donor database and CRM for the flaw that lets one supporter reach another's record?
Yes - it is one of the first things we test for a Berkeley nonprofit. We check the authorisation model behind your donor and constituent CRM: whether a logged-in supporter or portal user can change an identifier and read another donor's gift history, pledge amount or contact details, whether record identifiers can be enumerated, and whether staff roles are enforced per request rather than only at the login screen. This is the IDOR and broken object-level authorisation class, and it is the quiet way donor PII leaks without a single password being stolen.
How do you test for the email fraud that reroutes grants and donations to an attacker?
Business email compromise is the loss that hurts a mission most, because the money is often gone before anyone notices. We test the conditions that let it happen: whether your Microsoft 365 or Google Workspace tenant allows password-only sign-in without phishing-resistant MFA, whether mailbox forwarding rules and OAuth app grants can be added silently, and how a payment-change or wire request would be authorised. We phish under agreed rules to see who clicks and what a stolen session yields, then map the fixes to the exact settings that close the redirect path.
We run an advocacy group that handles sensitive information - do you test for targeted, not just opportunistic, attackers?
Yes. Advocacy, human-rights and community organisations hold information about activists, beneficiaries and vulnerable people that draws hacktivists and, sometimes, state-aligned actors - not only ordinary criminals. For those engagements we run assumed-breach and data-exfiltration scenarios: we start from a foothold and test how far an intruder could move toward the records that would expose a person's identity or location, and whether that movement would be detected. The goal is to protect the people you serve, not just the servers.
Which rules and standards actually apply to a Berkeley nonprofit?
The comfortable assumption that nonprofits are exempt is wrong. If your organisation meets the thresholds, CCPA/CPRA applies, and the CPPA's cybersecurity-audit and risk-assessment duties reach organisations that process personal information at scale - which many donor and beneficiary databases do. If you take card donations you inherit PCI DSS 4.0, and its Requirement 11.4 expects penetration testing of the payment environment. If you deliver a service to other organisations you may face SOC 2. Grant funders and enterprise partners increasingly send security questionnaires, and NIST CSF or CIS Controls Implementation Group 1 give you a right-sized baseline to answer them.
Your team is in the Gulf - how does the time gap actually work for a Berkeley engagement?
We will be straight with you: CyberFortify is a Gulf-based firm on UTC+3, ten to eleven hours ahead of Berkeley, with no California office and no local staff. We work a deliberate daily overlap window - our late afternoon and evening is your morning - kept open for stand-ups, live triage and read-outs so a small team is never left waiting. Testing continues overnight while you are offline, so findings are usually sitting in your shared channel when the Berkeley day starts.