For an NGO, data protection involves decisions about why information is collected, who may use it and how people can exercise applicable rights. Installing an ERP or choosing a European hosting location does not answer those questions. The system needs to support an approved governance model.
Where the General Data Protection Regulation, or GDPR, applies, begin with a processing map and clearly assigned responsibilities. Translate those decisions into records, permissions and workflows that can be tested. Keep legal interpretation distinct from the technical controls used to implement it.
Which processing and controller responsibilities apply?
The European Commission's GDPR application guidance explains that scope can include relevant processing connected to an EU establishment and certain activities by organisations outside the EU. Nonprofit status does not, by itself, answer the applicability question. Obtain an assessment suited to the NGO's actual activities.
The controller determines the purposes and means of processing; a processor acts on the controller's behalf. Identify these roles for each relationship rather than assuming every partner or supplier has the same status. An organisation can have different roles in different processing activities.
Record the decision in the compliance register, with source, scope, responsible reviewer and review trigger. Keep other applicable privacy regimes visible as separate requirements where relevant.
Purpose and necessity determine the data collected
Create a processing inventory for beneficiary services, staff administration, donor relationships and other relevant activities. Describe the purpose, data categories, people concerned, recipients and systems involved. Review the appropriate lawful basis and any additional conditions for sensitive information with the responsible specialist.
The Commission's GDPR principles guidance provides the foundation for purpose limitation, minimisation and retention decisions. Consent is not a universal substitute for assessing the processing context.
Apply the same purpose and necessity checks to beneficiary forms and records. A case-management purpose may justify different information from an aggregate donor report. Avoid copying identifiable records into a reporting database simply because a connector makes that convenient.
| Inventory Field | Practical Question |
|---|---|
| Purpose | What specific activity needs the information? |
| Data | Which fields are necessary for that activity? |
| Authority | What reviewed basis and conditions apply? |
| Recipients | Who receives information and for what purpose? |
| Retention | What event and rule govern review or disposal? |
| Systems | Where do copies and exports exist? |
Processors and recipients need defined responsibilities
Document the responsibilities of hosting providers, implementation partners and other recipients according to their assessed roles. Agreements and instructions should match the actual processing, including support access, subcontracting, return or deletion of data and assistance with relevant requests.
Ask suppliers to describe where processing occurs and who can access records. A hosting-region selection does not explain every support, backup or subcontractor arrangement. Where international transfers are involved, obtain the appropriate assessment rather than assuming a geographic label resolves the issue.
For a partner referral, identify the minimum information needed, recipient purpose and authorised route. Preserve the sharing decision and applicable controls. Do not let a routine export become an unrestricted duplicate database with no owner or retention rule.
Support rights, retention and incident workflows
Design a controlled intake process for relevant requests. Identify the responsible reviewer, identity checks appropriate to the context, records to search and the basis for the response. Requests may require judgement; an automatic delete button should not decide whether other obligations justify retaining particular records.
Map connected systems and exports so the team understands the full information footprint. Define how corrections, restrictions or approved deletions are coordinated where applicable. Keep evidence of the response without retaining unnecessary copies of the original sensitive material.
Specify access, audit and recovery controls alongside the privacy workflow. An incident workflow should identify who investigates, who assesses legal obligations and how evidence is preserved. Configure escalation to support the applicable obligations rather than embedding an unsupported universal response rule.
Translate governance into testable requirements
The ERP requirements checklist should turn approved decisions into observable behaviour. Use three concrete tests. A programme reporting role receives aggregate counts without case notes. A user whose assignment ends loses case access. An authorised reviewer can retrieve the records needed for a request.
Test with test data and include exports, interfaces and existing sessions. A restriction visible in the main screen may fail elsewhere. Keep the expected result, observation and remediation owner with each test.
Review the design when purposes, fields, recipients or integrations change. A new reporting use may require a fresh assessment even if the underlying database remains the same. Maintain ownership of the processing inventory and avoid treating implementation sign-off as the end of privacy governance.
Higher-risk processing needs assessment before configuration
A beneficiary system may combine health information, referrals and records about children. Explain why each sensitive field is needed and who receives it. Establish how long copies persist. Assess the harm that unauthorised disclosure could cause. A consent checkbox cannot resolve all of those questions.
The European Commission's GDPR obligations guidance explains the EU assessment responsibilities. For UK GDPR, the ICO's DPIA guidance identifies high-risk processing that requires assessment. Use the relevant EU or national authority's guidance for other jurisdictions. Record the applicable legal analysis before turning it into form fields and retention rules.
Map transfers, support access and subprocessors
List where production data, backups, exports and support copies can be accessed. Identify recipients and their roles, including subprocessors. Storage in one region does not by itself establish that access from elsewhere is appropriately governed. Ask the privacy adviser to determine whether a transfer mechanism or additional assessment is required for each route.
Consider a referral to an overseas delivery partner. Agree the purpose, minimum data, permitted onward sharing, security measures and retention responsibility. Test whether the system can provide only the approved subset. Keep the sharing decision and recipient agreement linked to the access configuration.
When a subprocessor or support location changes, reassess the affected route and contractual notification arrangements. The vendor assurance review should confirm the service boundary, while the NGO retains responsibility for its own processing decisions.
A processor register that includes support copies
| Service | Role To Assess | Information Needed | Change Trigger |
|---|---|---|---|
| ERP hosting | Processor for the defined service | Contracting entity, regions, subprocessors, retention and security duties | Region or subprocessor change |
| Support platform | Recipient of authorised support information | Redacted fields, access countries and deletion route | New support provider or access location |
| AI service | Role under the actual processing arrangement | Permitted inputs, retention, onward use and access controls | Model service or data-use change |
Record the actual legal entities and agreements before acceptance. These are service categories, not a list of Causeway subprocessors. Before introducing higher-risk case processing, determine whether the applicable regime requires a DPIA. Record that decision, including the sensitive data and vulnerable people involved. Keep the assessment decision and mitigation tests with the processing record.
Map each obligation to its control, evidence and reviewer in the Global Compliance Controls Matrix. Link each processing purpose to permitted access, retention decisions and tested rights-handling routes.
Conclusion
Start with the purpose of processing and the responsibilities of each party. Translate the approved privacy decisions into tests for access, exports, requests and retention. Where an assessment identifies higher risk, complete the required review before introducing the processing. Keep the register current when recipients or uses change. A sound ERP workflow gives staff a usable route to fulfil those responsibilities and makes exceptions visible to the people who must decide them.
Scope your privacy controls with Causeway
Causeway supports configurable finance, reporting, approval and recordkeeping controls within a global NGO operating platform. Evaluate those controls against your reviewed requirements for privacy purposes, record access, retention and processor responsibilities. Start with one sensitive case workflow, its permitted fields and the recipients involved. Test access expiry, a records request and a support export against the privacy decisions your organisation has approved.
Frequently asked questions
Is consent required for every processing activity?
No. Determine the appropriate lawful basis and any additional conditions for the particular activity under the applicable rules. Consent should not be added automatically to every form. The system should support the reviewed approach and the relevant information provided to people.
Does hosting in europe guarantee compliance?
No. Location is only one part of the assessment. Purposes, lawful processing, access, supplier responsibilities, rights handling and other obligations still matter. Review the full service arrangement, including support and subcontractor access, with the appropriate specialist.
How do controller and processor roles differ?
A controller determines the purposes and means of processing, while a processor acts on its behalf. Assess the actual relationship rather than relying only on contract labels. Different processing activities can give an organisation different roles and responsibilities.
