Security & Data Protection Pack

This document describes how MELscope is built, hosted and operated, and what happens to your project and beneficiary data inside it. It is deliberately specific, and it is deliberately honest about what MELscope does not yet have. If a control matters to your organisation and is not listed here, assume we do not have it and ask us.

1. At a glance

2. What MELscope does not have

We would rather you learn this here than in month three of a contract.

If your procurement process has a hard requirement for any of the above, MELscope will not pass it today, and we will tell you so rather than let you discover it late. Several of these are on our roadmap; none should be assumed to exist because it is common in larger products.

3. Hosting and infrastructure

MELscope runs on managed infrastructure rather than self-managed servers, which means the underlying patching, physical security and hardware lifecycle are handled by providers who are independently audited for it.

• Application database, authentication, file storage and server-side functions run on Supabase, hosted on Amazon Web Services in the Asia Pacific (Sydney) region, ap-southeast-2. Your project data is stored in Australia.
• The web application itself is a static front end delivered through Cloudflare. It holds no data: every read and write goes to the database over an authenticated, encrypted connection.
• Physical security, hypervisor and host patching are AWS's responsibility under their shared responsibility model. AWS holds ISO 27001, SOC 1/2/3 and equivalent certifications.
• Database engine is PostgreSQL 17, kept current on the provider's general-availability release channel.

4. Access control and tenant isolation

This is the control that matters most in a multi-tenant system, so it is described precisely.

• Row-level security (RLS) is enabled on every application table without exception (39 at the time of writing), and every one of them carries at least one access policy. Isolation is enforced by the database itself, not by application code — a bug in the front end cannot expose another organisation's rows, because the database will not return them.
• Membership-based access. A signed-in user sees only projects they have been explicitly added to. There is no organisation-wide or platform-wide read path for ordinary users.
• Five roles, least privilege by default: owner (full control, billing, team management), editor (day-to-day data entry and editing), field officer (data entry only), evaluator (read-only), stakeholder (restricted read-only summary). Read-only roles cannot write through the interface or the API.
• Server-side privileged operations — approving access requests, generating AI reports, reading quota — run as audited database functions that re-check the caller's identity and project membership server-side. They do not trust the browser.
• AI report generation is restricted to the project owner and is refused server-side for any other role.

5. Beneficiary privacy

Client projects routinely record data about the individuals they serve. MELscope treats that as the most sensitive data on the platform.

• Share links never expose beneficiary names. The server-side function that builds an external viewer's snapshot does not read the beneficiary name field at all — pseudonymised display IDs, disaggregation counts and site-level figures only. This is enforced in the query, not by hiding a column in the interface.
• Share links never expose stakeholder contact details. Where a client records a contact person, role, email address or telephone number against a stakeholder organisation, those four fields are visible only to the client's own project team. The snapshot function names every field it returns, and none of them is a contact field, so an evaluator sees who the stakeholders are and how they matter but not how to contact them. The restricted stakeholder tier does not receive the register at all.
• Share links expire and can be revoked. Every external link carries an expiry date, a revocation flag and an access tier, and is issued and withdrawn by the project owner.
• Share-link access is logged, and the log cannot be edited. Each link records when it was opened, which evidence documents were opened through it, and which indicators were reviewed, and the project owner can see this against every link they have issued. The log is written only by the server-side functions that serve the link; it has a read policy and no write policy at all, so no user of the account can alter or erase it. It deliberately records no IP address and no browser user-agent — the questions an auditor asks are what was opened and when, and collecting more than that about an external reviewer would be data we have no need to hold.
• Evidence files are served through short-lived signed links. An external reviewer never receives a storage credential. Each file is released as an individually signed URL that expires in five minutes, issued only after the server has re-checked the token, its tier, its expiry and revocation status, and confirmed the document belongs to that link's own project.
• Consent is recorded per beneficiary record, so a client can evidence the lawful basis on which an individual's data was collected.
• Disaggregated counts — by sex, youth status and disability — are held as aggregate figures against indicators, and are what flows into reporting rather than identifiable records wherever the client's counting method allows it.

6. Artificial intelligence and your data

MELscope can draft donor reports from your live project data using a large language model. Because this is the feature clients ask about most in review, it is set out in full.

• Model and provider: Claude (Anthropic PBC), called server-side from MELscope's own infrastructure. The API credential is held as a server-side secret and is never present in the browser.
• What is sent: indicator baselines, targets, actuals and variances; results-framework statements; activity descriptions; site records; document titles and categories; and aggregate, pseudonymised beneficiary counts. Your uploaded donor template text is sent when you use the custom-template feature.
• What is not sent: beneficiary names. The system prompt additionally instructs the model never to refer to individuals by name and never to invent data not present in the input.
• Owner-initiated only. No data is sent to the model in the background; a report is generated only when the project owner clicks to generate one. Usage is metered and logged per account.
• Training: Anthropic's commercial terms state that data submitted through the API is not used to train their models. MELscope does not use your data to train any model.
• If you would prefer no AI processing at all, tell us and we will disable the feature for your account. Every report format remains available as a standard templated export.

7. Sub-processors

These are the third parties involved in delivering MELscope. We will give you at least 30 days' notice before adding a new sub-processor that handles personal data.

8. Backup, continuity and data durability

MELscope's production database runs on a paid provider tier with automated daily backups retained for seven days. Projects are not suspended for inactivity, and the database is not dependent on a free service tier.

What this does and does not mean for your programme:

• Recovery granularity is one day, not one minute. In a worst-case restore you could lose up to a day of entries made since the last backup. Point-in-time recovery, which reduces this to minutes, is available as a paid addition — tell us if your programme requires it and we will quote it and confirm in writing once enabled.
• Backups are for our recovery from infrastructure failure, not a self-service time machine. We cannot roll back one project, or one deleted record, without restoring more broadly. Treat your own exports as the tool for recovering from a mistaken edit.
• You can export everything, at any time, to Excel — indicators, data entries, beneficiary records and evidence registers. We still recommend a scheduled export at each reporting cycle as your own independent copy, held under your organisation's control. This right survives the end of your subscription.
• Uploaded evidence documents remain downloadable in their original form.
• We do not offer a contractual uptime guarantee. We are a small operation and will not promise an availability figure we cannot staff against. If your procurement requires a service-level agreement, raise it with us before signing rather than after.

9. Vulnerability management and known issues

We run the platform's automated security linter against the database and review the findings. Open items as at the version date of this document, disclosed in full:

No findings at error severity were open at the version date. We will disclose material findings to affected clients rather than wait to be asked.

10. Incident response

• If we become aware of a personal data breach affecting your data, we will notify you without undue delay and in any event within 48 hours of becoming aware, by email to your registered account owner.
• Our notification will describe what happened, the categories and approximate volume of data involved, the likely consequences, and the measures taken or proposed.
• We will assist you in meeting your own regulatory notification duties. As processor, we do not notify your regulator or your beneficiaries on your behalf.
• Report a suspected vulnerability or incident to info@melscope.com. We aim to acknowledge within one business day. We will not pursue good-faith security researchers who report responsibly and do not access other clients' data.

11. Data retention, export and deletion

• Your data remains yours. We do not sell it, share it with other clients, or use it to train models.
• During your subscription, you may export all project data to Excel at any time, including after your project closes.
• On termination, you keep read-only access for export for a defined wind-down period. On written request we will delete your data and confirm deletion.
• Backups and logs may retain residual copies for a short period after deletion; these expire on their normal cycle and are not restored into production.

12. Personnel

• MELscope is built and operated by a small team with a professional monitoring-and-evaluation background, working in the same sector as our clients.
• Administrative access to production is limited to those who need it to operate the service, and is protected by the provider's own account controls.
• Everyone with access is bound by confidentiality obligations covering client and beneficiary data.
• We access client project data only to operate the service, to fix a fault, or when you ask us to — for example during guided setup or support.

13. Legal framework

MELscope is operated from Papua New Guinea, where the right to privacy is protected under Section 49 of the Constitution of the Independent State of Papua New Guinea. Because our clients implement projects funded by international donors — including the GEF, the European Union, DFAT and MFAT — we align our practices with internationally recognised data-protection principles, including those of the EU General Data Protection Regulation: lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. Our Data Processing Agreement is available for signature, and our Privacy Policy sets out how we handle personal data.

14. Document control and contact

This pack is reviewed at least annually and whenever there is a material change to hosting, sub-processors or security posture. If you are completing a vendor security questionnaire and need something not covered here, send it to us and we will answer it directly rather than leave a gap.

ImpactSpring Smart Farm
Port Moresby, Papua New Guinea
info@melscope.com