Walk through plain-language readiness questions, mark what is done or uncertain, and download a filled PDF your team can use as a short action plan.
For each area, choose the closest status. If you are not sure, choose Not sure. That answer is useful because it shows what to verify next.
These questions ask whether people log in safely and whether old or unnecessary access is removed.
MFA means a second step after a password, such as an authenticator app or security key. Start with email, file storage, finance, donor, HR, cloud, and admin accounts.
Example: Done: all staff use MFA for email and file storage, but finance still needs confirmation.
Admin accounts can change settings, read sensitive data, or remove other users. Funders want to know they are not shared or forgotten.
Example: Needs work: two old admin accounts still need to be removed.
When staff, contractors, or volunteers leave, someone should remove access from email, files, vendors, shared inboxes, and devices.
Example: Not sure: HR has a checklist, but vendor accounts are not always included.
A password manager helps people use unique passwords instead of reusing one password across many accounts.
Example: Needs work: leadership uses one, but program staff do not.
These questions help you explain what sensitive data exists and whether it can be recovered.
Sensitive data can include donor, beneficiary, legal, staff, finance, program, source, or operational records.
Example: Not sure: donor and finance systems are known, but old shared folders have not been reviewed.
Retention means how long you keep records before archiving or deleting them. Different data may have different expectations.
Example: Needs work: donor records are understood, but program files are kept indefinitely.
Backups should cover the information your team needs to keep operating after deletion, ransomware, account compromise, or vendor failure.
Example: Done: files and CRM are backed up, but restore permissions need review.
A restore test proves you can recover data, not just that a backup setting is turned on.
Example: Needs work: backups exist, but no one has documented a restore in the last year.
These questions ask whether your team knows who does what when something goes wrong.
The responder coordinates first actions. The decision maker can approve disruptive steps like disabling accounts or notifying stakeholders.
Example: Done: operations director responds first; executive director makes notification decisions.
Include IT, security, legal, insurance, hosting, and platform support. After-hours paths matter.
Example: Not sure: IT contact is known, but legal and insurance contacts are not in the incident plan.
Templates reduce panic when you need to notify staff, funders, customers, beneficiaries, or affected people.
Example: Needs work: no drafts exist yet.
A tabletop is a short practice conversation. It exposes gaps before the incident is real.
Example: Needs work: we have talked informally, but never practiced a scenario.
Use this section to turn the checklist into a short action plan.
Pick the issue that creates the most risk or would be hardest to explain to a funder.
Example: No recent access review, so former staff may still have access to shared folders.
Write a practical next step. It does not need to solve everything.
Example: Export current users, remove stale accounts, and save the access review record.
A name and a proof point make this easier to act on.
Example: Operations director by Aug 15; evidence is an access review spreadsheet and screenshots.
Turn checklist gaps into credible answers and evidence for funders, boards, and insurers.
Define responders, decision makers, first-hour steps, and scenario playbooks for common incidents.
Worksheets, checklists, templates, and buyer guides for small teams improving security.
Secure Origin helps nonprofits and NGOs turn this checklist into a Protect The Organization roadmap, remediation plan, validation scope, or funder-ready evidence package.