For an NGO, a website may be much more than a public information resource.
It may collect contact information, programme applications, beneficiary registrations, volunteer details, donor information, employment applications, feedback, case information and documents.
Some organisations also connect their websites to donor CRMs, programme management systems, payment platforms and internal databases.
This means that website security can become a data protection issue, not simply a technical IT issue.
A compromised NGO website can expose information about people who may already be vulnerable. Depending on the organisation’s work, that could include children, refugees, survivors of abuse, people receiving healthcare or social services, programme participants, activists or communities facing other forms of vulnerability.
For NGOs operating in Kenya, data protection obligations also need to be considered alongside technical security. The Office of the Data Protection Commissioner (ODPC) oversees Kenya’s data protection framework, including registration and data breach reporting mechanisms for data controllers and processors.
A secure NGO website therefore needs to address both cybersecurity and responsible personal-data handling.
Not all information collected by an NGO carries the same level of risk.
A general newsletter subscription may contain only:
A beneficiary application might contain considerably more information:
If this information is compromised, the consequences may go far beyond an ordinary website security incident.
Potential consequences include:
The security requirements should therefore be proportional to the sensitivity and potential impact of the data being processed.
Beneficiary data can include any information that identifies or can reasonably be linked to an individual.
Examples include:
Depending on the NGO’s activities, this could include:
The more sensitive the information, the more carefully the organisation should consider whether it needs to collect it through a public website at all.
One of the most effective security measures is also one of the simplest:
Do not collect unnecessary personal data.
Every additional field creates another piece of information that needs to be:
For example, if an application form only needs to establish eligibility, there may be no reason to collect a national identification number during the initial enquiry.
Instead, the organisation could:
This reduces the amount of sensitive information exposed through the public-facing website.
Before securing an NGO website, understand where the data goes.
Create a simple data flow such as:
Beneficiary
↓
Website Form
↓
Web Server
↓
Application Database
↓
CRM / Programme System
↓
Authorised Staff
↓
Reports / Backups
Then ask:
You cannot adequately secure data flows that you have not mapped.
An NGO website handling personal information should use HTTPS.
HTTPS encrypts communication between the user’s browser and the website.
This is particularly important when users submit:
An SSL/TLS certificate is now a basic requirement for any professional website handling personal data.
However, HTTPS should not be treated as complete website security.
It protects data in transit between the browser and server, but it does not automatically protect:
HTTPS is foundational, not sufficient.
Administrative accounts are among the most attractive targets for attackers.
An attacker who obtains an administrator’s credentials may be able to:
NGOs should therefore implement strong authentication for administrative and staff accounts.
Recommended controls include:
Where supported, multi-factor authentication should be enabled for administrators and other privileged users.
Not every employee needs access to every beneficiary record.
A communications officer may need to publish website content.
A programme officer may need access to programme information.
A finance officer may need access to financial records.
A system administrator may need technical access.
These should not automatically be the same permissions.
Implement role-based access control (RBAC).
For example:
| Role | Example Access |
|---|---|
| Website Editor | Pages, news and publications |
| Communications Manager | Website and media |
| Programme Officer | Relevant programme records |
| Finance Officer | Financial information |
| System Administrator | Technical configuration |
| Super Administrator | Restricted high-level access |
The principle should be:
Users receive the minimum access required to perform their responsibilities.
OWASP’s 2025 Top 10 places broken access control at number one and recommends server-side enforcement, deny-by-default access and controls based on ownership and user roles.
A common application security mistake is assuming that hiding something in the interface prevents users from accessing it.
For example:
/user/records/123
must not automatically allow another logged-in user to change the URL to:
/user/records/124
and see another person’s information.
Access control must be enforced on the server.
The system should determine:
Is this authenticated user actually authorised to access record 124?
This is particularly important for beneficiary portals and programme management systems.
The website administration area should receive additional protection.
Depending on the platform, consider:
Avoid sharing one administrator account among an entire communications team.
If five people use the same credentials, it becomes difficult to determine:
Individual accounts provide accountability.
Outdated software is a common source of security vulnerabilities.
This applies to:
The current OWASP Top 10:2025 specifically identifies software supply chain failures as a major application security risk. It highlights risks across dependencies, build systems and software distribution rather than treating security as a problem limited to the application’s own code.
For WordPress websites, this means maintaining:
For custom applications, it means maintaining:
Every plugin, package or third-party service introduces another dependency.
Before installing a component, ask:
This is particularly important for NGO websites handling sensitive information.
A plugin that provides a convenient feature may not be worth introducing if it creates unnecessary access to beneficiary data.
Website forms are often the entry point for beneficiary information.
A secure form should address:
Never assume that browser-side validation is sufficient.
For example, a form might require a telephone number through JavaScript, but an attacker can bypass browser validation and send a crafted request directly to the server.
Security validation must therefore occur server-side.
User input should never be trusted.
Potentially dangerous inputs can appear through:
Applications should use appropriate validation, parameterised queries and safe APIs.
Injection remains one of the OWASP Top 10:2025 categories, covering attacks such as SQL injection and cross-site scripting. OWASP recommends keeping data separate from commands and queries and using safe APIs or parameterised interfaces.
This is particularly important when an application stores sensitive beneficiary information.
NGO websites often allow users to upload:
File uploads create additional security risks.
A secure upload system should consider:
Do not assume that checking whether a filename ends in .pdf makes an upload safe.
File content and server behaviour also need to be considered.
This is a particularly important issue for beneficiary systems.
Suppose an uploaded document is stored at:
https://example.org/uploads/beneficiary-document.pdf
If anyone who knows or guesses the URL can access it, the application’s login system may be irrelevant.
Sensitive documents should generally be stored in protected storage and served only after the application verifies that the requesting user is authorised to access them.
This principle applies to:
Encryption should be considered both in transit and at rest.
Use HTTPS/TLS to protect data moving between:
Sensitive information stored in:
may also require appropriate encryption.
Not every database field necessarily needs application-level encryption.
The appropriate approach depends on the sensitivity of the information, the threat model and the architecture.
The important point is to identify which information would cause serious harm if exposed and apply appropriate controls.
If your NGO operates user accounts, passwords should never be stored as readable text.
Passwords should be stored using secure password hashing mechanisms provided by the application’s framework or a trusted authentication system.
This means that even database administrators should not be able to retrieve users’ original passwords.
Users should also be discouraged from reusing passwords across systems.
Modern NGO websites increasingly communicate with:
APIs can therefore expose substantial amounts of information.
Every API should be evaluated for:
An API that returns beneficiary records should never rely solely on the assumption that users will not discover the endpoint.
An API response might technically work while still exposing excessive information.
For example, an endpoint might return:
{
"name": "Jane Doe",
"phone": "...",
"email": "...",
"date_of_birth": "...",
"national_id": "...",
"medical_information": "..."
}
when the interface only needs:
{
"name": "Jane Doe"
}
Returning unnecessary information increases the potential impact of a compromised account or application.
API responses should therefore expose only the fields required for the specific operation.
A security strategy should protect against both unauthorised access and data loss.
NGOs should maintain reliable backups of:
Backups should be:
Most importantly:
A backup that has never been restored successfully is not a proven backup.
Test restoration periodically.
A common mistake is securing the production database while leaving backups poorly protected.
If the database contains sensitive beneficiary information, an unencrypted backup stored in an accessible cloud folder can create the same security problem as an exposed production database.
Apply appropriate security to:
Access to backups should be restricted to authorised personnel.
Security logs can help an NGO detect suspicious activity.
Monitor events such as:
Logging should not mean collecting every possible piece of personal information.
Logs themselves can contain sensitive information and should therefore be protected.
OWASP’s 2025 Top 10 includes logging and alerting failures as a distinct security risk, emphasising that useful logging without appropriate alerting may not provide an effective security response.
A secure system should not simply record events.
It should help identify suspicious patterns.
For example:
Depending on the system, these events can trigger alerts.
No security system is perfect.
An NGO should assume that an incident could occur and establish a response plan before one happens.
The plan should define:
During a real incident, uncertainty about who is responsible can waste valuable time.
For NGOs operating in Kenya, cybersecurity needs to be considered alongside the Data Protection Act framework.
The ODPC provides a mechanism for data controllers and processors to report personal data breaches.
Section 43 of the Data Protection Act establishes breach notification obligations. The statutory framework provides for notification to the Data Commissioner without delay and within 72 hours of becoming aware of a qualifying personal data breach, while processors have obligations to notify controllers without delay and, where reasonably practicable, within 48 hours.
The precise legal obligations depend on the circumstances of the incident and the organisation’s role as a controller or processor.
NGOs should therefore establish their incident-response procedures before an incident occurs and obtain appropriate legal or data-protection advice where necessary.
The distinction matters.
A data controller determines how and why personal data is processed.
A data processor processes personal data on behalf of another organisation.
An NGO may act as a controller for some activities and a processor for others, depending on the relationship and processing activity.
The ODPC recognises these roles within Kenya’s data protection framework.
Your organisation should understand its role for each significant data-processing activity rather than assuming that one classification applies to everything.
Your website may send information to external providers such as:
Before sending personal data to a third party, understand:
Third-party integrations should be included in the NGO’s data mapping exercise.
Analytics tools are useful, but they should not become accidental repositories of sensitive information.
For example, avoid sending personal information through:
A URL such as:
/programme/application?name=Jane-Doe&phone=0712345678
could expose personal information through browser history, server logs, analytics systems and referral data.
Use opaque identifiers where necessary and avoid putting sensitive information into URLs.
Email is often used to communicate beneficiary information.
However, ordinary email should not automatically be treated as a secure system for transmitting sensitive records.
Where possible:
The safest solution is often to avoid transmitting sensitive data through email in the first place.
Even a technically secure website can be compromised through a staff member.
Common threats include:
NGOs should provide regular security awareness training.
Staff should understand:
Developers should not normally test new functionality directly on the live website.
Use separate environments such as:
Development
↓
Staging
↓
Production
This reduces the risk of:
Most importantly, do not use real beneficiary data in development environments unless there is a clear, justified and appropriately controlled reason to do so.
Use synthetic or anonymised data wherever possible.
Security should be tested before the website goes live.
Depending on the project, testing can include:
For more complex systems handling high-risk information, an independent security assessment may be appropriate.
The OWASP Top 10:2025 provides a useful baseline for application security reviews, covering areas such as broken access control, security misconfiguration, cryptographic failures, injection, insecure design and authentication failures.
One of the most expensive mistakes an NGO can make is treating security as a final checklist.
For example, consider a beneficiary application system.
If privacy is considered from the beginning, the team can design:
If these issues are ignored until development is finished, correcting the architecture may be significantly more difficult.
Security should therefore be part of:
For NGOs handling beneficiary data, privacy should be considered during product design rather than only after the system is built.
Ask questions such as:
This approach can improve both privacy and security.
Keeping personal data indefinitely increases risk.
An NGO should establish appropriate retention periods based on:
When information is no longer required, there should be a process for:
The website and associated systems should support these policies.
Data exports can be extremely powerful and extremely dangerous.
A staff member with access to an “Export All Beneficiaries” function could potentially download thousands of records in seconds.
Ask:
In some systems, it may be preferable to provide reports containing aggregated information instead of unrestricted access to raw personal records.
NGOs often publish beneficiary stories to demonstrate impact.
This can be valuable for fundraising and accountability, but it also creates privacy considerations.
Before publishing a story, consider:
A photograph combined with a name, location, programme and personal circumstances may reveal significantly more information than any individual field suggests.
NGOs working with children should apply particularly careful controls to children’s personal information.
This can include:
Before publishing information about children, organisations should consider applicable legal requirements, safeguarding policies, consent requirements and the potential risks to the child.
The safest approach is not always to publish identifiable information simply because permission has been obtained.
The potential consequences should also be considered.
A practical NGO security checklist can include:
If your NGO is commissioning a new website or beneficiary platform, ask the agency:
A good agency should be able to answer these questions clearly.
If your NGO uses WordPress, security requires particular attention to the entire WordPress ecosystem.
This includes:
Avoid installing unnecessary plugins simply because they offer convenient features.
Use reputable, actively maintained software and establish a maintenance process for updates and security monitoring.
A professionally engineered WordPress website can be secure, but security cannot be delegated entirely to WordPress itself.
Custom development provides greater control over the application architecture, but that control also creates responsibility.
A custom application should be developed using secure coding practices and reviewed against recognised application-security principles.
Security considerations should include:
Custom development is not a shortcut around security.
It increases the importance of having competent developers and a sustainable maintenance plan.
Launching a secure website does not mean the organisation has permanently solved security.
New vulnerabilities appear.
Staff change.
Software becomes outdated.
Third-party services change.
Attack techniques evolve.
New integrations are added.
The organisation’s data requirements change.
Security should therefore be treated as an ongoing operational process.
A sensible annual programme may include:
More frequent monitoring may be appropriate for systems handling high-risk information.
The most important principle is simple:
Protect beneficiary information according to the harm that could result if it were exposed, altered or lost.
This means moving beyond the question:
“Is our website secure?”
and asking:
“What could happen to the people we serve if this information were compromised?”
That question changes how an organisation approaches:
For NGOs, cybersecurity is ultimately about protecting people, not just protecting servers.
Zedafrica designs and develops websites and digital platforms for organisations that need to communicate, engage audiences and manage complex digital experiences.
For NGOs handling beneficiary information, security can be incorporated from the beginning of the project through:
Whether your organisation is building a new public website, redesigning an existing NGO website or developing a beneficiary-facing platform, security should be considered part of the architecture from day one.
