A community platform earns trust before its first user profile is created. The decisive work happens in the data model, the defaults, the permissions and the decisions an organisation is willing not to make.
A community connection should not require a personal dossier
Imagine a resident who wants to find a local volunteer opportunity. Another person is looking for a mentor. A third wants to discover a community activity without explaining their personal circumstances to strangers.
A digital service could help these people find relevant opportunities. But it could also collect far more information than the task requires: detailed biographies, precise location histories, availability patterns, personal challenges, private messages, photographs and inferred interests.
The difference between a useful community service and an intrusive one is often established long before the interface looks finished.
SamfunnsBro’s concept and public descriptions identify community connections, resources, peer mentoring and volunteer opportunities as intended functions. This article does not assume that each function is already implemented or that a production personal-data architecture has been approved. It therefore sets out a proposed design approach, not a description of implemented controls.
The central proposition is simple: design the service around the minimum information needed to make a useful connection, rather than designing a large profile and later trying to protect it.
1. Privacy is a product decision, not a footer link
A privacy notice is necessary, but it cannot compensate for a data model that collects unnecessary information or exposes it to the wrong audience.
The General Data Protection Regulation (GDPR) requires personal data to be processed lawfully, fairly and transparently; collected for specified purposes; limited to what is necessary; kept accurate; retained no longer than needed; and protected appropriately. It also places accountability on the controller. These principles are not optional interface preferences.
Norway is part of the European Economic Area. The GDPR became applicable in Norway through the Norwegian Personal Data Act, which entered into force on 20 July 2018. A SamfunnsBro service processing personal data in Norway must therefore be designed against the applicable Norwegian and EEA framework, not an informal idea of what a community app usually collects. [1][2]
The Norwegian Data Protection Authority, Datatilsynet, explains that privacy must be considered throughout the development of a system and that privacy-friendly settings should be the default. The European Data Protection Board’s Guidelines 4/2019 provide further interpretation of GDPR Article 25 on data protection by design and by default. [3][4]
For SamfunnsBro, that means privacy requirements should be written into product decisions, acceptance criteria and technical architecture before real people are invited to register.
2. Start with purposes, not profile fields
A common product-design mistake is to begin with a list of fields: name, age, address, skills, interests, health, availability, photographs and biography. The team then tries to explain why each field might be useful.
A safer method reverses the sequence.
First define the specific service purpose. Then identify the minimum data needed to achieve it. If a field has no clear purpose, it should not be collected merely because it may be useful later.
A proposed purpose register for an early SamfunnsBro design could look like this:
| Service purpose | Minimum data to consider | Design boundary |
|---|---|---|
| Account and security | Account identifier, authentication data and essential security events | Do not expose authentication or security data in public profiles |
| Discover a volunteer opportunity | Broad area, opportunity category and optional availability | Avoid exact home address and continuous location tracking |
| Request a mentor introduction | A short request, relevant topic and contact preference | Do not require a detailed personal history |
| Coordinate an agreed activity | Project-specific contact and scheduling information | Limit access to people responsible for that activity |
| Handle a safety or conduct report | Information necessary to assess and respond to the specific report | Keep case records separate from ordinary community profiles |
| Improve service reliability | Aggregated operational measures where feasible | Do not use private messages or sensitive case records as general analytics |
This is a design proposal, not a legal determination that these fields or purposes are necessary. Each processing activity needs its own assessment.
The purpose register should also state what the platform will not do. For example, it should not quietly repurpose volunteer activity to infer a person’s health, employability, financial circumstances or social vulnerability. A new use requires a fresh compatibility and lawful-basis assessment; it should not be smuggled into a broad phrase such as “improving the community experience”.
Datatilsynet’s guidance on the fundamental privacy principles emphasises purpose limitation and data minimisation. The amount of data collected should be limited to what is necessary for the stated purpose. [5]
3. Identify who is responsible before choosing the technology
A platform may involve a project owner, a software developer, a hosting provider, a messaging service, analytics tools and local partner organisations. Technical involvement does not automatically determine legal responsibility.
The organisation that decides why and how personal data is processed may be a controller under GDPR. A supplier processing personal data on the controller’s behalf may be a processor. If two or more organisations jointly determine purposes and essential means, joint-controller responsibilities may arise. These roles must be assessed from the actual arrangement, not assigned by branding or assumption.
Before procurement or deployment, SamfunnsBro should identify:
- The legal entity that will act as controller for each processing activity.
- Whether any partners are independent or joint controllers.
- Which suppliers act as processors and what processing instructions they receive.
- Where data is stored and accessed, including relevant subprocessors and international transfers.
- Who can approve access, exports, retention exceptions and deletion.
- Who receives and coordinates privacy requests and suspected incidents.
Where a supplier is a processor, the required contractual terms and documented instructions must be addressed. A vendor’s security statement is useful evidence, but it does not transfer the controller’s accountability.
This work should produce a simple, current data-flow map. It should show where information enters, where it is stored, which systems receive it, who can access it, and when it is deleted or anonymised.
4. Choose a lawful basis for each purpose
Consent is important, but it is not a universal permission slip.
GDPR Article 6 provides several lawful bases for processing personal data. Depending on the real relationship and purpose, these may include consent, necessity for a contract, a legal obligation, protection of vital interests, a task carried out in the public interest or legitimate interests. The appropriate basis must be assessed for each processing purpose. It cannot be selected simply because a checkbox is easy to implement.
If SamfunnsBro relies on consent for an optional activity, that consent must be freely given, specific, informed and unambiguous. People must be able to refuse without losing access to something they should otherwise be able to use. Withdrawal must be possible and as easy as giving consent. The European Data Protection Board explains these requirements in Guidelines 05/2020. [6]
This has practical consequences:
- Joining a community should not automatically mean agreeing to promotional emails.
- A person should not have to make a profile public to request a private introduction.
- Optional photographs or testimonials should have a separate, understandable choice.
- Consent to one activity should not silently authorise unrelated analytics or partner sharing.
- A person should be told what happens when consent is withdrawn and which records may still need to be retained on another lawful basis.
Some information requires additional care. Data revealing health, political opinions, religious beliefs, ethnicity, sexual orientation or other special categories is subject to GDPR Article 9 restrictions and requires both an Article 6 basis and an applicable Article 9 condition. A community service should not ask people to disclose such information unless a clearly defined and lawful service purpose makes it necessary.
A “wellbeing” feature can easily invite disclosures that the platform is not equipped to handle. The safest first design may be to provide links to resources and voluntary contact routes without building personal health profiles.
5. Make privacy the default experience
The first version of a community platform should not expose more than users deliberately choose to share.
A proposed SamfunnsBro default could include:
- Profiles are private or visible only to a limited, clearly explained audience until the user changes the setting.
- Exact home addresses are not displayed to other participants.
- Broad geographic areas are used where location is needed for matching.
- Availability is shared only for a specific opportunity or introduction.
- Contact details are not copied into public pages or searchable directories.
- Activity indicators, read receipts and online status are disabled unless there is a clear need and a meaningful choice.
- Promotional communications are separate from service messages.
- Public sharing of photographs, stories or project contributions requires a distinct decision.
Privacy-friendly defaults should not make the service unusable. The aim is to give people control without forcing them to understand a complex settings panel before they can participate.
The EDPB’s Article 25 guidance and Datatilsynet’s Norwegian guidance both place emphasis on building safeguards into processing from the start and ensuring that, by default, only the personal data necessary for each purpose is processed. [3][4]
6. Give data a lifecycle: collect, use, review, delete
A record should not remain in a platform simply because storage is inexpensive.
For every category of personal data, the design should define:
- Why it is collected.
- Who can access it.
- How it is corrected.
- When it is reviewed.
- When it is deleted or anonymised.
- Which narrow legal or operational exceptions may justify retention.
A proposed lifecycle for an ordinary community account might include account creation, active participation, a period of inactivity, a user-initiated closure request, deletion or anonymisation, and a limited retention of records that must lawfully be preserved.
The exact periods should not be invented in a product workshop. They should be determined from the actual purpose, legal obligations, security needs and documented risk assessment.
A user-facing account page should make it possible to find the privacy notice, request access, correct inaccurate information and submit a deletion request. It should also explain that some information may need to be retained where a legal obligation or another valid exception applies. The platform should not promise absolute deletion from every backup or audit record if that is not technically or legally accurate.
A retention schedule should be more specific than “we keep data while your account is active”. Messages, incident reports, security logs, project records and newsletter subscriptions serve different purposes and should not automatically share one retention period.
7. Separate ordinary participation from sensitive case handling
Community services sometimes receive disclosures that were never intended to become profile data. A user may report harassment, describe a health concern, ask for help with a difficult situation or mention another person’s circumstances.
The platform should not treat every conversation as a reusable source of product insight.
A proposed architecture should separate at least three information domains:
Community operations: account details, opportunity participation and ordinary service coordination.
Restricted case handling: safety reports, complaints and information needed for a specific response. Access should be limited to authorised roles, with a documented reason for access and a defined retention process.
Service analytics: aggregated or otherwise appropriately minimised information used to understand whether the service is functioning. Private message contents and sensitive case details should not be repurposed as general engagement analytics.
Pseudonymisation can reduce exposure in some workflows, but pseudonymised data remains personal data where it can still be linked back to a person. Anonymisation is different and should not be claimed unless re-identification is no longer reasonably possible in the relevant context.
The separation should exist in the technical design and access model, not merely in a written policy.
8. Treat security as a continuous control, not a launch checklist
A privacy-friendly service still needs proportionate information security.
A proposed baseline includes:
- Multi-factor authentication for privileged and administrative accounts.
- Role-based access and least-privilege permissions.
- Encryption in transit and appropriate encryption at rest.
- Secure credential storage and managed secrets.
- Logging of privileged access and material administrative actions.
- Tested backup and recovery procedures.
- A process for reviewing suppliers, dependencies and security updates.
- A documented route for receiving, assessing and escalating suspected incidents.
The precise controls depend on the systems, threats and data involved. A checklist is not proof that the service is secure. Controls need owners, test evidence and periodic review.
The organisation should also decide what happens when a supplier changes its subprocessor list, moves data to another region, introduces a new analytics feature or uses customer content to train or improve a model. These changes can alter the risk and may require a fresh legal, contractual and technical assessment.
9. Assess high-risk processing before it starts
A Data Protection Impact Assessment (DPIA) is required under GDPR Article 35 where a type of processing is likely to result in a high risk to the rights and freedoms of individuals. It is not automatically required for every small community website, nor should it be skipped simply because the project is small.
A service involving vulnerable people, sensitive information, systematic monitoring, extensive profiling or consequential automated decisions may raise risks that need careful assessment. The actual processing must be examined against the applicable criteria and supervisory guidance.
Datatilsynet describes four core DPIA elements: a systematic description of processing and its purposes; an assessment of necessity and proportionality; an assessment of risks to people’s rights and freedoms; and the measures intended to address those risks and demonstrate compliance. [7]
For SamfunnsBro, the DPIA screening should happen before selecting features that could create high-risk processing. If a DPIA is required, it should be completed before that processing begins. Where a high residual risk remains and the GDPR’s conditions are met, prior consultation with the supervisory authority may be necessary.
10. Keep people in the governance loop
Privacy is not only a legal relationship between an organisation and an individual. In a community service, it is also a question of power.
Can a participant understand why a record exists? Can they challenge an incorrect description? Can they participate without making their personal story public? Can they leave without losing control of information that is no longer needed?
A proposed SamfunnsBro data charter could make five commitments visible:
- Purpose clarity: explain why each category of data is used.
- Minimum collection: do not request information simply because it may be useful later.
- Private by default: make sharing a deliberate choice.
- Meaningful control: provide workable routes for access, correction, objection, withdrawal where consent is the basis, and deletion requests.
- Accountable change: explain material changes in data use and provide a route for questions or complaints.
A small user-advisory group could review plain-language notices, onboarding screens and proposed new data uses before release. This would not replace legal review or formal accountability, but it could expose confusing assumptions that a technical team might otherwise miss.
The organisation should also publish a concise change log when material data practices change. Trust is weakened when a service quietly changes what it collects or who receives it.
11. A 30-day design pilot that uses no real participant data
The first pilot should test the architecture, not people’s willingness to surrender information.
Days 1–7: Purpose and responsibility map. List the proposed service functions, purposes, data categories, controller and processor candidates, and what the platform explicitly will not collect. Assign an owner to every unresolved decision.
Days 8–14: Data-flow and threat review. Draw the path of each data category from collection to deletion. Review public/private boundaries, administrator access, supplier access, export paths and incident scenarios.
Days 15–21: Prototype with synthetic data. Use fictional profiles and test records. Verify that private profiles remain private, optional sharing can be refused, access restrictions work, and deletion and correction journeys behave as designed. Do not use real personal data in demonstrations or screenshots.
Days 22–26: Rights and transparency testing. Ask a small group to review the proposed privacy notice and interface using fictional examples. Test whether people can understand the purpose, recipient, retention and choices without legal assistance.
Days 27–30: Readiness review. Record gaps in lawful basis, contracts, security, retention, DPIA screening and operational ownership. Decide whether to revise the design, proceed to a separate controlled test or stop.
This is a proposed design schedule, not a claim that a compliant production platform can be built in thirty days. No real-user pilot should begin until the controller, legal bases, notices, supplier arrangements, security controls and any required DPIA are resolved.
12. Measure restraint as well as growth
A community platform should not define success only by registrations, messages or time spent in the app.
A privacy-by-design scorecard could track:
| Area | Proposed indicator | What it demonstrates |
|---|---|---|
| Data minimisation | Share of requested fields with a documented purpose | Whether collection is justified |
| Default privacy | Percentage of profile and sharing settings that begin in the privacy-protective state | Whether users must actively protect themselves |
| Access governance | Privileged accounts reviewed and access exceptions documented | Whether sensitive access is controlled |
| Retention | Data categories with approved review and deletion rules | Whether records have an end-of-life process |
| User control | Time and completion rate for access, correction and deletion workflows | Whether rights are usable in practice |
| Supplier governance | Relevant processors and subprocessors documented and reviewed | Whether external dependencies are visible |
| Security readiness | Critical controls tested and unresolved findings tracked | Whether controls have evidence |
| Transparency | Material data-use changes explained before implementation | Whether the organisation communicates honestly |
These indicators are proposed management measures, not statutory metrics or evidence of current SamfunnsBro performance. They should be reported with scope and limitations. A low number of privacy requests, for example, does not prove that people understand or trust a service.
Conclusion: build a bridge, not a database of people
The promise of SamfunnsBro is to make it easier for people to discover opportunities, exchange knowledge and contribute to their communities. That promise does not require collecting every detail about the people who participate.
A responsible platform can begin with a narrow purpose, a small data model, private defaults, clear accountability and a tested path for user rights. It can add complexity only when a real need is demonstrated and the legal, ethical and technical consequences have been assessed.
The strongest signal of trust may be what the service chooses not to collect.
For Jarlhalla, this is an opportunity to make digital innovation more credible: not by claiming that technology automatically creates community, but by showing how engineering discipline, transparent governance and respect for people can shape technology that deserves to be used.
References and source notes
- Norwegian Data Protection Authority (Datatilsynet), “Regulations — General Data Protection Regulation.” Explains that the GDPR became applicable in Norway on 20 July 2018 through the EEA framework. Official guidance.
- Norwegian Personal Data Act, Act of 15 June 2018 No. 38. English translation on Lovdata; entered into force 20 July 2018. Legislation.
- Datatilsynet, “Innebygd personvern og personvern som standard.” Last changed 27 July 2023. Explains privacy throughout system development and GDPR Article 25. Official guidance.
- European Data Protection Board, Guidelines 4/2019 on Article 25: Data Protection by Design and by Default. Final version, 20 October 2020. Official guideline.
- Datatilsynet, “Grunnleggende personvernprinsipper.” Last changed 16 July 2019. Covers lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity/confidentiality and accountability. Official guidance.
- European Data Protection Board, Guidelines 05/2020 on consent under Regulation 2016/679. Adopted 4 May 2020. Official guideline.
- Datatilsynet, “Hvordan gjennomføre en DPIA?” Last changed 27 July 2023. Summarises the core elements of a data protection impact assessment under GDPR Article 35(7). Official guidance.
- European Commission, “Obligations — Information on the processing of personal data.” Explains information that organisations must provide, including purposes, categories, legal basis, storage period and rights. Official guidance.