What a security review should and shouldn't include

NGOs buy security reviews for ordinary reasons. A funder asks for one. A staff member clicks a suspicious link and the organization gets scared. A grant application requires evidence that systems have been checked.

All three reasons are fine.

The problem starts when the review has no clear boundary. The organization pays for a report, receives a long list of alarming words, and still does not know what needs attention this week.

A useful review explains what was checked, what was not checked, how serious each finding is, and what the organization should do next.

What a review should include

Automated vulnerability scanning

The reviewer should scan the agreed public systems for known weaknesses. This may include exposed services, outdated software versions, weak TLS settings, missing security headers, and common configuration problems.

The report should identify the affected host or service. A raw scanner export is not enough. Someone needs to check whether the finding applies and explain the practical risk.

Server and configuration review

The reviewer should inspect server configuration, firewall rules, exposed ports, update status, administrative access, logging, and backup settings.

For a self-hosted NGO service, this is often where the most useful work happens. A server may have strong application code but expose an administration panel to the whole internet. A backup may run every night but store every copy on the same machine.

The review should state which systems were inspected and which configuration files or dashboards were included.

Authentication and permissions review

The reviewer should check how people sign in and what they can access.

That includes administrator accounts, shared accounts, multi-factor authentication, password policies, service accounts, and access granted through groups. The review should ask who can see beneficiary data, who can export it, and who can delete it.

Departed staff matter here. Someone who left six months ago may still have access to email, a file store, a VPS, or the organization’s domain registrar. A good review checks the offboarding process against actual accounts.

A prioritized findings report

The report should rank findings by practical risk and explain the reason for the ranking.

A critical issue should not sit beside a low-impact header recommendation with the same visual weight. Each finding should name the affected system, describe the evidence, explain the possible consequence, and give a recommended next action.

The organization should be able to assign an owner and a deadline from the report. “Improve security” is not an action. “Remove the former contractor’s administrator account from the file server by Friday” is.

One walkthrough call

The reviewer should explain the findings in a call with the people who manage the systems.

The call gives the operations manager a chance to ask what can wait, what needs immediate attention, and what a fix might disrupt. It also lets the reviewer correct misunderstandings before the report gets forwarded to a funder without context.

What a review should not promise

Penetration testing

A security review is not automatically a penetration test.

Penetration testing involves a defined attempt to find and demonstrate exploitable weaknesses. It may include application testing, network testing, authenticated testing, or social engineering, each with its own scope and controls.

That is a different discipline and usually a different price. A reviewer should not call a configuration review a penetration test because the latter sounds more impressive.

Formal compliance certification

A reviewer can assess controls and document gaps. A reviewer does not issue a formal compliance certification unless they are acting within the authority and process required by the relevant scheme.

“Certified secure” is not a useful promise from a general security reviewer. Security depends on scope, time, configuration, and later changes. A report from August cannot certify that every system will remain safe in November.

A full application code audit

A review may look at application configuration, exposed endpoints, dependencies, and selected code paths. That is not the same as reviewing an entire codebase.

A full code audit needs its own scope. It may examine authorization logic, input validation, data handling, secrets, file uploads, background jobs, and error paths. The hours add up quickly, especially when the application has grown without tests or documentation.

The client should know whether the reviewer read code, ran tools, inspected deployment settings, or performed all three.

Fixing everything

Remediation should be scoped and quoted separately.

A reviewer can propose fixes and help the organization prioritize them. They can also implement agreed changes under a separate statement of work. Bundling all remediation into the review creates an incentive to inflate findings because every new issue may become billable work.

Separation does not mean the reviewer should abandon the client after the report. It means the organization can see the cost of assessment and the cost of repair as different decisions.

Red flags before you sign

A review with no written boundaries is a problem. The proposal should name the domains, servers, applications, accounts, dates, and testing methods included. It should state what the reviewer will not touch.

A report made entirely from scanner exports is another warning. Tools produce useful signals. They do not understand the organization’s workflow, data sensitivity, or actual exposure without human review.

Be careful with “certified secure” language. A responsible reviewer describes evidence and limits. They do not promise a permanent state that no one can guarantee after the review ends.

Fear-based upsells also deserve attention. A reviewer may find a serious issue and explain the consequence plainly. They should not use vague threats about funders, regulators, or public exposure to sell work outside the agreed scope.

What to prepare

Before commissioning a review, prepare a list of systems. Include domains, VPS instances, hosted tools, shared drives, form platforms, email administration, and any application used to store beneficiary information.

Prepare a list of people with administrator access. Include staff, contractors, former staff, service accounts, and the person who controls the domain registrar. Mark accounts that use shared credentials.

Write down the last backup test date. Not the last backup date. The last date someone restored data and confirmed that the result was usable.

Those three documents give the reviewer a starting point and give the NGO a way to judge whether the review covered the systems that matter.