Legal · Privacy
Privacy Policy
Draft for legal review · not yet in force
Contents
01Who we are, and in what role
FCRM is operated by [LEGAL ENTITY NAME], registered at [REGISTERED ADDRESS], registration number [REGISTRATION NUMBER] (“FCRM”, “we”, “us”).
There are two different relationships, and they matter:
- Case and feedback data. For everything a person submits through a customer's forms — feedback, complaints, misconduct reports, attachments, the accountability trace — the customer organisation is the data controller and we act as its processor, on documented instructions, under the Data Processing Agreement. We do not decide what happens to a case; the organisation does.
- Account and business data. For staff accounts, billing, support and website analytics, we are the controller.
If you submitted a report and want to know what happened to it, contact the organisation you submitted to. We cannot act on that request as a controller, and we will forward it to them where you ask us to.
02What we process
As a processor, on behalf of a customer organisation
- Submissions through public forms and in-person intake: the answers given, any files or audio attached, the language, and the channel used.
- The case record and its accountability trace: who viewed, what changed, when, and what was answered.
- Optional submitter contact details, where the form asks for them and the person consents. Tracking references are generated per case; sensitive submissions return no reference.
- Technical data needed to operate intake: timestamps, coarse device and network metadata, and rate-limiting signals. Where a project policy requires it, phone numbers are hashed or discarded.
As a controller
- Staff account data: name, work email, role, organisation, authentication events and multi-factor enrolment state.
- Billing data: organisation details, plan, seats, invoices and payment records. Card data is handled by the payment provider and never stored by us.
- Support correspondence.
- Server logs for security and reliability, retained briefly and access-restricted.
03Sensitive case content
Some reports contain special category data within the meaning of Article 9 GDPR — for example allegations of sexual exploitation or abuse, health information, or information revealing ethnic origin or religious belief. This data exists because a person chose to report it, and because the law and the Core Humanitarian Standard require organisations to be able to receive it safely.
Our design assumes this data is present in every mechanism we host:
- Sensitivity is determined before a submission is stored as a case. A sensitive intake is sealed on arrival and encrypted to the key of a named recipient selected by the organisation's sensitivity policy.
- Once sealed, access is revoked server-side. The submitter and everyone outside the named recipient role lose access immediately; the record shows only that a restricted case exists.
- Every view, export and change to a sensitive case is written to an append-only, hash-chained audit trail.
04Why we process it
| Purpose | Basis (GDPR Art. 6) |
|---|---|
| Providing the service to a customer organisation (as processor) | Performance of a contract with the controller (Art. 6(1)(b)); for special category data, the controller's Art. 9 condition applies and is set by them |
| Staff accounts, authentication, billing | Contract (Art. 6(1)(b)) |
| Security, fraud prevention, abuse limits | Legitimate interests (Art. 6(1)(f)) |
| Legal obligations — tax, accounting, lawful requests | Legal obligation (Art. 6(1)(c)) |
| Product emails to account holders | Contract, or consent where required |
We do not sell personal data. We do not use case content for advertising, profiling or model training.
05Who we share it with
Sub-processors
We use a small set of infrastructure providers to run the platform. The current list, with purpose and location, is maintained in the DPA and we notify customers before adding one that processes case content.
| Provider | Purpose | Location |
|---|---|---|
| Cloudflare | Compute, database, object storage, email routing, bot protection | EU jurisdiction (data pinned) |
| Key management provider | Envelope encryption keys for sealed cases | EU / EEA |
| Payment provider | Invoicing and card processing | EU / EEA |
Other recipients
- The customer organisation and the people it designates, under its own access rules.
- Referral partners, only where the controller records consent and makes the referral.
- Authorities, where legally compelled. Where the law allows it, we redirect the request to the controller, who holds the case.
- Professional advisers and auditors, under confidentiality.
06Where it lives
Customer data is stored in the region selected for the organisation — today the European Union — and database and object storage are pinned to that jurisdiction at the infrastructure level. Where a transfer outside the EEA is unavoidable (for example, a support engineer outside the EEA), it is covered by the European Commission's Standard Contractual Clauses with a transfer impact assessment, or by an adequacy decision.
07How long we keep it
- Case data: for the retention window the customer organisation sets per category and per project. At the end of the window, records are purged and a deletion certificate is produced.
- Audit trail: retained for the same period as the case it belongs to; the chain integrity record may be retained longer in hashed form, which does not identify anyone.
- Trial organisations: data is due for deletion 60 days after the trial ends unless the organisation converts.
- Account and billing records: for the life of the account, then as long as tax and accounting law requires.
- Server logs: short-lived, typically 30 days.
08How we protect it
Encryption in transit and at rest, envelope encryption for sealed cases, mandatory multi-factor authentication for staff, append-only hash-chained audit logs verified nightly, rate limiting and bot protection on public intake, and least-privilege access with a named-owner requirement. The full picture is on the Security page.
If a personal data breach occurs that affects customer data, we notify the affected controller without undue delay and within 48 hours of becoming aware, with the facts then known — so the controller can meet its 72-hour obligation.
09Your rights
Subject to applicable law, you can ask for access to your data, correction, deletion, restriction, portability, and you can object to processing based on legitimate interests. Where processing rests on consent, you can withdraw it at any time.
For case data, the controller is the organisation you submitted to; we will forward your request if you ask us to, or you can contact them directly.
You have the right to complain to a supervisory authority. Our establishment is in North Macedonia: the Agency for Personal Data Protection ([AZLP CONTACT]). If you are in the EU, you may complain to your local authority. We would rather you told us first: [PRIVACY EMAIL].
Data Protection Officer: [DPO NAME / EMAIL].
10Cookies and similar technologies
- Public reporting forms set no marketing cookies and require no account. A session cookie may be set only to protect the submission itself and expires when you close the form.
- Staff application uses a session cookie that is strictly necessary for authentication. Without it, no one can sign in.
- This website sets no analytics or advertising cookies. Traffic measurement, where used, is aggregate and cookie-free.
11Changes and contact
We will publish any material change to this policy on this page and, where the change affects customers, notify account holders by email at least 30 days before it takes effect. The version and date at the top always identify the text in force.
Questions, requests and complaints: [PRIVACY EMAIL] · [POSTAL ADDRESS].