Security statement

This statement describes, in general terms, how EcclesiaOne protects data. The platform is operated by Orravo Web Technologies. It supports the Privacy Policy and the Data Processing Agreement. It is written to be accurate about what the platform does today, so it does not claim protections that are not yet in place.

1.Our approach

We aim to apply security measures that are appropriate to the sensitivity of the data EcclesiaOne holds, which includes religious, pastoral, safeguarding, children's, and financial data. Security is a shared responsibility: we secure the platform, and the institutions that use it secure their own access by managing roles, granting access only to those who need it, and enabling available protections such as two-factor authentication.

2.Access control

Access to data is controlled by role. Permissions are scoped to a tenant and to the level (platform, diocese, parish, school) at which a role applies, so that people see only what their role allows. Sensitive permissions are marked as such. Platform administrators at Orravo can access tenant data where strictly necessary to operate and support the service, and in limited cases can act on behalf of a user to diagnose problems; this access is logged.

3.Authentication

Passwords are stored as salted hashes using a strong hashing algorithm (Argon2id) and are never stored in readable form. Users can enable two-factor authentication using a time-based one-time code, with recovery codes. Sessions and verification and reset tokens expire and are stored hashed.

4.Encryption

In transit. The platform is served over HTTPS only. We send an HTTP Strict Transport Security header with a two-year lifetime covering the platform and its subdomains, so that a browser that has visited us once will refuse to connect over plain HTTP afterwards. Session cookies are marked HttpOnly and SameSite, and are marked Secure in production so they are only ever sent over an encrypted connection.

At rest. Three classes of data are encrypted by the platform itself, on top of whatever encryption our hosting and database providers apply to their own storage:

• Pastoral and spiritual notes and case summaries, using a sealed-box scheme with a key derived from the assigned priest's own credentials. The key is not stored in readable form, and the encrypting server cannot read the result back. If the priest changes their password the key is re-wrapped in the same operation.
• The password for an institution's own email relay, using AES-256-GCM.
• An institution's SMS gateway credentials, using AES-256-GCM.

Other data in the database is not separately encrypted by the application. Whole disk or volume encryption for the database and for file storage is provided by our database and storage providers under their own terms, and is not something we operate ourselves.

5.Integrity of records

Sacramental registers are protected with a tamper-evident hash chain, so that changes to the official record can be detected. Significant actions on records are recorded in audit logs that capture who acted, what they acted on, when, and in many cases the values before and after the change. Session records separately hold the IP address and browser the session was created from, and a user can review their own active sessions and end them.

6.Service providers

We use the service providers listed in the Sub-processor List for payments, messaging, hosting, storage, and AI. Payment-card data is handled by the payment providers and is not stored by EcclesiaOne. We require our providers to maintain appropriate security.

7.Monitoring and resilience

We would rather understate this section than overstate it.

What we do. Errors raised by the platform are captured and stored, with the page that failed, the technical detail, and the identifier of the signed-in user where there was one. Our administrators can review them, and they are deleted 90 days after the error was last seen. Significant actions are written to the audit log described in section 5. Sign-in attempts, two-factor challenges, and public form submissions are rate limited to slow down automated attacks, and public forms are additionally protected by a bot-detection service.

What we do not yet do. We do not run a round-the-clock security operations centre, and we do not have automated alerting that pages an engineer when something looks wrong. We have not been through a SOC 2 or ISO 27001 audit and we hold no security certification. We have not commissioned an independent penetration test. We do not lock an account automatically after repeated failed sign-in attempts, and our rate limits are held in the memory of each running instance rather than in a shared store, so a determined attacker distributing attempts across instances will get more attempts than the stated limit.

Backups. The platform does not run its own backup schedule. Backups of the primary database are those performed by our database provider under its own service terms, and our administrators can take a manual snapshot in addition. This is set out in the Data Retention and Deletion Schedule.

8.Breach response

If a personal data breach occurs, we will act to contain and investigate it, and we will notify affected institutions and, where required, the relevant authorities and affected individuals, within the timeframes set by the NDPA and, where applicable, the GDPR. For institutions, the notification commitments are set out in the Data Processing Agreement.

9.Reporting a vulnerability

If you believe you have found a security vulnerability in EcclesiaOne, please report it to [email protected] with SECURITY in the subject line.

We ask that you report it to us privately and give us a reasonable opportunity to fix it before telling anyone else; that you do not access, change, or download data that is not your own, and stop as soon as you have enough to demonstrate the problem; that you do not degrade the service for other people, for example by running automated scanning that affects availability; and that you do not use social engineering against our staff or the staff of an institution.

We do not run a paid bug-bounty programme. We will acknowledge your report and keep you informed of what we do about it.

10.Limits

No system can be guaranteed perfectly secure, and we cannot promise absolute security. We work to reduce risk and to improve our measures over time.

11.Changes

We may update this statement as our practices change. When we publish a new version, the version number and date on this page change.

12.Contact

For security questions, contact [email protected].