Privacy Notice

Version: 2026-11-05-centralized-6 · Effective date: November 5, 2026

A consolidated convenience copy of the current published documents. Each document retains its own version and effective date. The versioned legal pages and archive remain authoritative.

On this page

Who is responsible and how to contact us

Soteria is operated by Daniel Ashraf Ekdawi, an individual based in Cairo, Egypt. Legal/contact address: 1 Amin Al Shamsi Basha Street, Hegaz Square, Heliopolis, Cairo, Egypt. Contact Daniel about personal data and privacy rights at [email protected]. General support: [email protected]; telephone: +20 120 769 6771. This identifies the operator and privacy contact, without claiming incorporation, registered or accredited Data Protection Officer status, or regulatory approval. This notice explains personal-data processing for visitors, Account holders, managed Persons, Organization participants, guardians, reservation guests and people contacting us. Reading it, creating a record or accepting Terms is not blanket consent. Arabic is the primary maintained text and an equivalent English version is provided.

Soteria and your Organization

Soteria determines the purposes of its Account administration, service security, support and contractual records. An Organization determines its community activities, the information collected for them, and the users permitted to access its scoped records. For that Organization-directed processing, Soteria provides the platform on its documented instructions, subject to applicable law and the Organization Data Processing Agreement. The relevant role depends on the actual processing, not only its label. A Person may have no Account and may have separate global, Organization and Group profiles. Organization access does not make all profiles public or give every administrator access to every record. Ask the relevant Organization about its purposes, notices and authorized contacts. You may also contact Soteria directly; coordination with an Organization does not remove our own duties or applicable response deadlines.

Information we process

Account data includes login identifiers, contact information, password hashes, security settings, session/device records, recovery information and security/audit history. Profiles may include names, optional birth dates, contact details, addresses, locations, photos, relationships and custom fields. Organizations may keep membership and roles, attendance, event and assignment participation, check-in records, points, shop activity, communications, reservation answers and uploads. Religious participation and children's records can be sensitive personal data. Inquiries and support correspondence include the details and message you supply, such as your name, email, optional telephone, church/service name and approximate community size. Billing records can contain payer contact details, package/order information, amounts, payment status and provider references. Network and technical information can include connection metadata, request/security events and device or browser information needed by the service and its providers. We do not ask you to email passwords, recovery codes or full payment-card details.

Where information comes from

Information comes from you, Organization administrators and authorized users, guardians, invitations, reservation submissions, support correspondence and reviewed imports. Payment and email providers can return delivery or transaction status and references. Devices provide information used for selected functions, such as a push subscription or a location you choose to share. A record may therefore have been created by an Organization before the person has an Account or contacts Soteria. Organizations collecting information indirectly must provide the appropriate notice to affected people and establish lawful authority. A public notice alone does not prove that every person in an import has been informed or consented. Ask the responsible Organization or [email protected] if you want to understand the source of your record. General feedback accepts only PNG, JPEG or WebP screenshots. The server decodes and re-encodes them to PNG without original filenames or image metadata before mailbox storage/delivery; unsupported, animated or undecodable files are rejected. This is risk reduction, not universal malware certification. A receipt sent to an unverified optional address does not include the submitted report or attachments. Use the protected privacy-case route for necessary sensitive evidence.

Purposes, legal grounds and required information

We use Account and contact information to register and administer requested services, answer inquiries, provide support and manage the applicable agreement. These purposes rely on the applicable steps to enter into or perform a contract where that ground is available. Service security, fraud prevention, audit and necessary records must have the applicable legal justification, including a legal obligation or another lawful ground recognized in the relevant jurisdiction. A commercial interest is not assumed to authorize every processing activity. An Organization must determine and document the grounds for its community purposes. Where consent is required, it must be specific and valid; sensitive-data processing, children's data and international transfers have additional conditions. Consent is not inferred from a general Terms checkbox. Optional marketing needs its own choice; an inquiry or a transactional message is not a marketing subscription. Some information is necessary for a function: for example, login identifiers for an Account, an email address for a reply, or payer details for hosted checkout. Without it, that function may not be available. Optional profile fields and feature permissions are not all required to use every part of Soteria. Avoid submitting unnecessary sensitive information.

Sensitive information and children

Egyptian law treats religious information and children's personal data as sensitive. Required PDPC licensing or authorization and explicit written consent, including guardian consent for children where required by law, must be established for the relevant processing. Our product rule requires guardian consent for consent-dependent processing of data of a Person under 18; this is not a determination of contractual capacity. An Organization must verify the actual guardian and purpose. Membership, a relationship label, a managed record or an administrator's action does not grant consent. Authorized Organization users may record independently verified written consent from the actual legal guardian, including a guardian who has no Soteria Person or Account. The recorder identifies whether they are the guardian or are recording consent obtained from that guardian; collecting evidence does not confer guardianship. The record preserves identity/contact and claimed authority, verification method and protected references, purposes/categories, recipients, exact notice version and language, actual consent date, expiry, recorder/time and withdrawal. Historical review remains restricted to Super Admin reviewers. Rejected, withdrawn or expired evidence authorizes nothing. Public signup uses a self-reported age band for Account eligibility, not a profile birth date. An under-15 applicant can begin registration, but the Account remains pending and cannot log in. The responsible Organization must obtain the actual guardian’s written consent externally, verify their legal authority and record evidence specific to the Account request before activation. A guardian needs no Account, and an arbitrary email or OTP click is not proof of guardianship. The same rule applies to an existing invited managed Person and a newly registered Person. An unassigned request must be linked through a recipient-bound Organization invitation. Ages 15–17 and uncertain/conflicting age still require review; neither an age declaration nor a profile-purpose grant establishes contractual capacity or Account authority. Routine Organization administration uses authorized roles, feature policies and the Organization’s documented processing responsibilities. Registration, joining an Organization and creating an Organization are the main legal checkpoints. Creating a managed profile, importing people, recording attendance, administering assignments, booking, scoring, reporting or sending service notifications does not require a new per-person or per-file Super Admin approval. A legacy record or continued access is not documented consent or proof of adulthood. Organizations must still establish the lawful basis and additional conditions actually required for sensitive information and children. Recorded privacy restrictions, actual consent withdrawal or expiry, guardian Account conditions and legal holds continue to apply to their scope and purpose. Optional public photo disclosure and precise-location uses require specific authority for the intended purpose and recipients. A restriction affecting one person does not automatically stop unrelated people’s administration. Reports identify restricted coverage; an ordinary export cannot silently present omitted records as complete. Privacy-rights returns, cancellation and refunds retain their separate protected processes. AI-assisted import sends the selected file and relevant field context to OpenAI only after review of that Organization’s processing authority, provider and transfer arrangements. That Organization/provider authorization is reusable within its documented scope; a file-bound historical review is not expanded automatically. Private file upload and local confirmation do not send data to OpenAI. Address parsing runs locally and does not need an external AI-provider approval. These safeguards do not replace legally required consent, permits, contractual arrangements or professional review.

Who receives information

Authorized users receive information according to Organization/Group scope, role and feature permissions. Messages and notifications disclose their content to selected recipients. The operator and necessary service personnel may access information to operate, support and secure the service. Hosting, storage, backup, email and feature-specific providers process information needed for their services. Public images, public links you authorize, exports, downloads and offline copies can extend beyond the original application access boundary. Review what is shared and who receives it. We may disclose information when lawfully required or necessary for an applicable security or legal claim, with the required safeguards. We do not treat this notice as permission to sell your community records or use them for unrelated advertising.

Payments and hosted checkout

Soteria has a Paymob hosted-checkout integration. The production configuration verified for this notice uses test-mode credentials; test checkout is restricted to Super Admin and is not live customer collection. When checkout is used, including integration tests, Soteria sends payer name, email, phone, order reference, currency and amount to Paymob and receives transaction status and references for verification and records. Avoid unnecessary real personal information in tests. Payment details entered on Paymob's hosted page are handled by Paymob. Soteria's checkout integration does not collect or store the full card number or card security code. Paymob may also process network, device, fraud-prevention and legally required information under its own applicable terms and privacy notice; it is not necessarily acting only on Soteria's instructions for every purpose. Organizer-owned reservation payments are a separate domain and may involve the organizer's selected provider or manual payment evidence. No live approval, recurring authorization or exclusive Egypt storage is implied by the integration.

Maps, AI, push and automated rules

Maps, Places and geocoding use Google Maps Platform when the relevant features load or are used. Google can receive location/search queries and network/browser information. Browser permission for device location is separate from entering an address or viewing a map. AI-assisted imports send selected uploaded information and prompts through Soteria's AI service to OpenAI to produce a draft for human review. Provider retention and account controls apply: do not assume zero retention or immediate deletion. Only submit information you are authorized to share, minimize sensitive data, and check the draft before saving it. If you enable browser push, the service stores the device subscription and uses your browser's push infrastructure to deliver notifications. Push can reveal content on a device or lock screen; you can change browser permissions. Organizations may configure audience filters, reminders, scoring and other automated rules using community records. Such results depend on their configuration; ask the responsible Organization to explain or review a result that affects you. This notice does not authorize legally significant decisions about a person without the required safeguards. AI user import is disabled unless the operator records an unexpired Organization-specific approval after reviewing data authority, provider and transfer evidence. The same restriction applies to upload, analysis and confirmation of existing drafts. The current Responses request sets store:false to avoid unnecessary stored response state. Files are sent inline rather than through the OpenAI Files API. This does not establish Zero Data Retention: abuse-monitoring, exceptions and account/project controls remain separate and unverified. The AI service can temporarily cache drafts in process memory; local import drafts/files have a seven-day expiry and are removed through the existing cleanup process. Human review is still required.

Cookies and copies on your device

Soteria uses cookies for authentication/session handling, security and language preferences, and browser storage for application operation. IndexedDB and caches can hold authorized data, media and drafts for offline use and later synchronization. Local copies are still personal information; use an appropriate device and protect access to it. Offline copies may not immediately learn about a server-side change or revoked access until the device reconnects. Blocking necessary cookies or storage may prevent login, preferences or offline functions from working. You can use browser controls to remove site data or change location and notification permissions, but removal can discard unsynchronized work. Server deletion does not guarantee immediate removal of authorized exports, screenshots, public copies or information on other people's devices. This notice does not grant permission for unrelated tracking or optional marketing. First-party cookies and storage currently used: soteria_session — authentication cookie, up to 24 hours; server expiry/revocation is separate and logout clears the cookie. soteria_mfa_challenge — temporary MFA challenge, five minutes. soteria-locale — language preference, one year; later responses may renew it. soteria_email_cooldown_* — invitation/reset-email cooldown, 60 seconds; the name varies by action and subject. Local storage remembers sidebar state (soteria-sidebar-collapsed), dismissed push prompts (soteria-push-welcome-dismissed), recent search references (soteria:global-search:recent:v2:*) and workspace/feature selections (including soteria-feature-selection-v1:*). These have no general fixed automatic expiry; they can remain until overwritten, feature cleanup, browser eviction or site-data clearing. A dismissed prompt is not notification permission. Session storage holds saying rotation/history (soteria-spiritual-content-category and soteria-spiritual-content-recent:*) and release-reload coordination for the browser tab/session. IndexedDB soteria-offline holds authorized cached records/media, drafts and pending work. Cache Storage soteria-shell-* and soteria-application-shell-* holds offline/application shell assets; worker version cleanup and browser controls apply. Offline records do not have a product-wide fixed deletion deadline. Removing site data can discard unsynchronized work. This describes our first-party storage, not every cookie or network identifier used by a separately used provider such as hosted checkout or maps. Provider-specific processing follows the feature and provider disclosures. Introducing unrelated analytics or marketing tracking requires its own prior legal assessment and valid permission where required; this notice does not authorize it.

Providers, countries and international transfers

Soteria uses the providers identified in the Subprocessors / International Data Transfers supplement. The operator’s non-secret metadata review on 29 October 2026 reported the app/database server as Hetzner hel1-dc2 in Helsinki, Finland; SMTP delivery as AWS eu-central-1 in Frankfurt, Germany; and the backup endpoint as Backblaze eu-central-003. Backblaze documentation maps that endpoint region to Amsterdam, Netherlands; that is provider-supported inference, not a complete inventory of every copy. Zoho .com endpoints correspond to its US data-centre domain under provider guidance, without establishing all tenant, support or onward locations. R2 bucket jurisdiction/placement, AI and monitoring project regions, payment/push destinations and support/onward processing remain separately unverified. These reported settings are not exclusive residency guarantees or a fresh certification of every production account. Required Egyptian transfer authority, recipient roles, applicable contracts and sensitive-data conditions must be established separately. Neither encryption, general Terms nor guardian permission alone establishes them. Contact [email protected] before affected sensitive processing.

How long information is kept

Information is retained for the relevant service and lawful purpose, including necessary security, support, contractual, financial, legal-claim and compliance records. Organizations must review their own records and instructions. Account closure, leaving an Organization, cancellation and deletion are separate actions. Legal acceptance and consent evidence is preserved where necessary to demonstrate what was agreed or authorized; withdrawal does not erase the earlier evidence. Soteria’s working category schedule is pending professional review. Active relationships last only while their purpose is required; dormant profiles are reviewed 12 months after that purpose ends. Person/profile recovery history has a 90-day period; unreferenced media has a proposed 90-day period after final removal. Attendance/event personal history is reviewed after 3 years, assignments/results after 2 years from activity/season end, and reservation/guest answers/uploads after 12 months from event end or cancellation. Inquiries and resolved feedback text have 12-month periods after closure/resolution; feedback attachments have 90 days. These periods require a known lifecycle trigger and do not assert completed universal automatic erasure. Proposed fiscal/billing records and closed security-incident evidence have 5-year periods; legal acceptance/contract evidence has a proposed 5 years after the relationship ends, and guardian/consent evidence while relied upon plus a proposed 5 years after reliance ends. Ordinary security logs have 12 months and general audit records 2 years, with immutable evidence subject to reviewed disposal. Specific legal holds pause otherwise-due deletion, identify an owner and reason, and normally require review every 90 days. An overdue review does not silently remove a hold. Existing support-mail rules remain 180 days for eligible sent-only threads and 365 days for archived threads, excluding unresolved delivery work. Login artifacts keep their short operational expiry; inactive sessions have at most 30 days. Import drafts/files keep 7 days and applicable AI process/cache data at most 24 hours. Applicable browser/offline queues have a 30-day review bound; this cannot certify erasure on disconnected devices. Local database backups keep the existing 30-day policy and off-site snapshots retain 14 daily, 8 weekly and 12 monthly selections. Changed/deleted object recovery currently keeps 365 days to support matching files for retained monthly database restores; the proposed 90-day period requires coordinated recovery review before shortening. Provider copies, retained immutable evidence and independent recipients require separate reconciliation.

Implemented cleanup and backup rules

Local backup archives default to a configurable 30-day cleanup threshold. Encrypted off-site database backup selection retains 14 daily, 8 weekly and 12 monthly snapshots. R2 recovery mirrors retain current files and dated changed/deleted-object history, with a 365-day history cleanup threshold. These are configured rules that depend on successful backup/cleanup operations, not proof that a particular record was erased on an exact day. Recovery copies are not all immediately editable. Approved deletion requests must be accounted for before restored data returns to ordinary use. Security maintenance prunes expired or consumed challenges and expired rate limits; expired or revoked sessions become eligible after the configured 30-day inactivity retention. Mailbox cleanup makes sent-only threads eligible after 180 days and archived threads after 365 days, excluding unresolved deliveries. These periods do not define the retention of every audit event, support record, invoice or provider copy. We do not promise immediate deletion from backups or devices, and do not claim that all other category periods have been approved.

Your rights and how to request them

Depending on the applicable law and circumstances, you have rights to information, access, correction, erasure, restriction, objection and portability, and to withdraw a specific consent. Contact Daniel Ashraf Ekdawi at [email protected] or the address above. State the relevant Account/Person, Organization and request using safe references; a Person does not need an Account to contact us. Do not send passwords, recovery codes or identity scans without an agreed protected channel. We may verify identity and authority proportionately, protect other people's rights and coordinate Organization-controlled information with its authorized contact. For Egyptian personal-data rights requests, we respond within six working days from submission; identity checks and internal coordination must not silently restart that deadline. Other applicable mandatory periods remain binding. A reasoned restriction or refusal must have an applicable legal basis; removing active information may not remove justified evidence or existing recovery copies immediately. Withdrawal ends authorization for future consent-dependent processing within the relevant scope, without retrospectively invalidating lawful past processing. It is different from deleting your Account or cancelling a subscription. You can complain to the Egyptian Personal Data Protection Center (PDPC) and pursue available judicial or other mandatory remedies without first obtaining our permission. No registration in Soteria or acceptance of new Terms is required merely to raise a privacy request.

Security, monitoring and changes

We use scoped access controls, Account security and authorization for private files. Monitoring strips user/request/context/breadcrumb information and redacts runtime message and exception values before sending application error events; remaining technical metadata and provider network processing are not guaranteed anonymous. Providers and authorized recipients have their own relevant security responsibilities. No system guarantees absolute security. We investigate and contain personal-data incidents and make regulator and affected-person notifications when and within the periods required by applicable law, coordinating with the responsible Organization as appropriate. Report a suspected privacy or security incident to [email protected] using safe details. This notice has a version and effective date; previous published versions remain accessible. We update disclosures when the processing changes. A notice update does not itself create consent, authorize a new purpose or replace a required contract, licence or transfer safeguard. A new consent must be obtained where the changed purpose requires it.