NGO ERP security must protect both financial authority and sensitive information. A user who cannot edit a payment screen might still be able to submit a payment through an interface. A restricted beneficiary record might remain visible in an export. Security requirements need to cover the whole path to the data and action, not only the visible menu.
Start with data classes, responsibilities and the consequences of misuse or loss. Then define testable access, audit, retention and recovery requirements. Request evidence for the configured environment rather than treating a security feature name as proof that the organisation's needs are met.
Data sensitivity determines access boundaries
Separate public information, ordinary operational records, financial authority and sensitive personal data. Identify the roles that need each class and the context limiting their access, such as assigned project, country or case.
For beneficiary records, a finance reviewer may need eligibility evidence without needing detailed case notes. Convert that distinction into object and field access rules. A report that joins tables should not bypass the restrictions applied to the original records.
Create an access matrix covering view, create, change, approve, export and delete actions. Include administrators and service accounts. Review incompatible responsibilities, such as maintaining supplier payment details and releasing the resulting payment, under the organisation's segregation-of-duties policy.
Test roles, MFA and privileged accounts
Multi-factor authentication, or MFA, strengthens the login process but does not determine what an authenticated user may do. Authorisation still needs to be enforced for each protected action and record boundary.
The OWASP authorisation guidance recommends denying access by default and checking permissions on every request. Use those principles to challenge an implementation that restricts navigation but leaves records available through another route.
Test an ordinary user, an approver, a delegated approver and an administrator separately. Try access to a record outside the user's country or project, including direct links and exports. Check whether revoked permissions affect an existing session as well as the next login.
Privileged access should have an approved purpose, identifiable user and appropriate review. Avoid routine use of shared administrator accounts. For temporary support access, define approval, scope, expiry and evidence of the actions performed.
Exports and interfaces are part of the access boundary
The integration design should define the permissions of each service identity and the operations it may perform. Read access for reporting does not imply authority to create suppliers, change bank details or approve payments.
Separate interface credentials from ordinary user passwords and establish an appropriate process for storage, rotation and revocation. Test what happens when a credential expires or a receiving service is unavailable. Avoid error logs that expose personal records or secrets unnecessarily.
| Boundary | Test To Include |
|---|---|
| Country records | Attempt retrieval using an unauthorised country identifier |
| Export | Check fields and row scope against the user's permissions |
| Approval interface | Attempt an action outside the service account's authority |
| Revoked role | Repeat a previously permitted operation |
| Support access | Confirm expiry and retained activity evidence |
Which audit fields explain a decision?
An audit record should name the actor and affected object. It should show what changed and when. For high-impact actions, keep the relevant old and new values or a link to the change record. Restrict access to that evidence according to its sensitivity.
Protect audit records from ordinary modification. Define the retrieval route and name the reviewer for exceptions. Logging everything without a review purpose can increase noise and sensitive-data exposure. Logging too little makes investigation impossible.
Test a supplier-detail change, an approval override and a role modification. Ask a reviewer who did not perform the action to reconstruct the sequence. If the evidence cannot support that explanation, revise the requirement before acceptance.
A useful audit event
Example audit event AUD-007 records an export-permission change:
| Field | Recorded Value |
|---|---|
| Time | 2026-03-15T10:02:00Z |
| Actor and subject | Admin-02 changes User-17 |
| Affected record | Award-A |
| Permission change | Export allowed becomes denied |
| Reason | Assignment ended |
| Authority | ACCESS-09 |
| Outcome | Success |
Keep credentials and case narratives out of this event. The follow-up test attempts the same export and records denial.
| Evidence Requested | What A Reviewer Should Establish |
|---|---|
| Access test results | Screens, direct requests and exports enforce the same scope |
| Key-management record | Named custody, rotation and recovery responsibilities |
| Restore exercise | Data point, elapsed recovery time and reconciled workload |
| Vulnerability record | Findings, prioritisation, remediation and retest |
| Incident procedure | Contacts, escalation, notification and evidence preservation |
Retention and recovery solve different problems
Retention requirements should follow record purpose and applicable obligations. Where relevant, the GDPR governance workflow should inform handling of personal data and requests. Do not assume one retention setting can cover financial records, case notes, audit evidence and temporary exports.
Define recovery objectives by business need. The recovery point objective sets the acceptable data-loss window. The recovery time objective sets the target time to restore the agreed service. Neither is established merely by saying that backups run daily.
Use a documented restore exercise for the selected workload. Include its attachments and permissions in the recovery requirement. Measure the result, check record consistency and record unresolved limitations. Include recovery of integrations and queued transactions where they affect business continuity.
Validate security evidence
Use the ERP demonstration checklist to connect claims to observed tests, then require appropriate deeper evidence for deployment. Documentation, architecture review, testing and contractual responsibilities serve different purposes. A certificate, where supplied, should be checked for its scope, organisation and validity rather than treated as universal coverage.
Assign owners for ongoing access reviews, incident handling, backup tests and vulnerability remediation. Security is not complete when configuration is accepted. Define how changes in roles, integrations and data use trigger reassessment.
Record gaps openly. A control planned for a later release should not be scored as currently demonstrated. Decide whether the gap blocks use, requires a compensating control or can be accepted by the appropriate risk owner.
Verify the service boundary behind security claims
Identify the legal entity and product covered by each assurance document. Then check its hosting region and support scope. ISO/IEC 27001 concerns an information security management system; it does not establish that every configuration of an ERP meets your requirements. A certificate held by a cloud infrastructure provider should not be presented as evidence covering all application operations.
Request the current certificate or relevant assurance report through an appropriate confidential review process. Record scope, period, exclusions, findings and customer responsibilities. The vendor trust evidence review separates this diligence from functional access testing.
Encryption needs an operational owner
Specify where encryption applies, who controls keys, how keys are rotated and how access is recovered or revoked. Ask whether support staff can decrypt production information and under which approval route. A statement that data is encrypted leaves these questions unanswered.
Maintain a subprocessor list tied to actual services and locations. Review change-notification arrangements and access from support locations as well as storage regions. Include logs, backups and temporary exports in the boundary.
Ask for recovery and incident evidence
Request a recent recovery exercise for the proposed service. Record how long restoration took and which data was recovered. Review the problems found and whether corrective actions are complete. Agree recovery objectives for the NGO's critical workflows and test how reconciliation resumes after restoration.
The incident process should name notification contacts, escalation coverage, evidence preservation and the responsibilities of both parties. A contractual notification commitment is useful only when it connects to a working response process that the NGO can invoke.
For the deployment decision, compare cloud and self-hosted responsibilities and trace data locations and cross-border access. A hosting-region label does not define the entire security boundary.
Divide cloud and self-hosted duties
| Duty | Managed Cloud Contract | Self-Hosted Contract | NGO Responsibility In Both |
|---|---|---|---|
| Operating-system patching | Identify the contracted operator | Name the NGO or managed-service operator | Track agreed maintenance and exceptions |
| Application updates | Confirm deployment and rollback owner | Confirm supplier package and local deployment owner | Approve business testing and timing |
| Backup and restoration | Obtain service scope and exercise evidence | Operate or contract backups and restore tests | Approve objectives and validate recovered business data |
| Identity and permissions | Confirm platform and identity-service boundary | Confirm local identity integration | Approve access and remove leavers |
| Incident handling | Agree provider/customer coordination | Agree infrastructure/application coordination | Maintain escalation contacts and response decisions |
These columns are procurement responsibilities to settle in the agreement, not assumed promises about a supplier.
Record who can request, review and approve each transaction in the Approval Matrix Builder.
Identify incompatible duties and compensating reviews with the Segregation-of-Duties Matrix.
Conclusion
Accept security requirements through observed behaviour across the full service boundary. A denied screen action should also be denied through exports, interfaces and active sessions. A recovered database should support a reconciled business process. Assign the remaining operating duties to the supplier, NGO or contracted operator before launch. Security acceptance is incomplete when a critical task has no owner, even if the feature exists and the assurance documents are current.
Review your Causeway security requirements
Discuss an ERP requirements assessment covering your access, audit and recovery requirements against Causeway. Share a data-classification summary and test examples of the boundaries your teams need to enforce.
Ask for evidence covering ordinary users, privileged accounts, integrations and exports. Confirm responsibility for configuration, hosting, incident response and recovery testing in the proposed scope. A useful discussion should identify what can be demonstrated and which controls require further technical review before sensitive data is introduced.
Frequently asked questions
Does MFA replace role-based access?
No. MFA helps verify identity during authentication. Role and object permissions determine what that identity may access or change. Test both, including sensitive actions through reports and interfaces rather than only through the main application menus.
How can an NGO test country-level data segregation?
Create test records in two country scopes and assign users different permissions. Attempt direct access, search, export and interface retrieval across the boundary. Record the expected and observed result, including what happens after a permission is revoked.
Are backups enough to prove recovery works?
No. A backup's existence does not establish that the required service can be restored correctly or quickly enough. Run a controlled recovery exercise, verify records and permissions, measure the result and document dependencies or gaps that remain.
