MAAT Funeral Services — Privacy & Retention Policy
Version 1.0 · Prepared November 11, 2026
Status: Pre-launch policy draft. This policy describes the current website build and proposes a retention schedule. The site has not been verified as deployed. Scheduled deletion is not implemented. The operator must confirm its legal identity, applicable requirements, providers, and retention procedures before this becomes the live policy. An effective date will be added when adopted; the preparation date is not an assertion that the policy is already in force.
Privacy contact: Info@Maatfuneralservices.com. Subject line: Privacy request.
1. Who this policy covers
This policy covers the MAAT Funeral Services website, service inquiry form, planning worksheet, and staff care desk. “MAAT,” “we,” and “our” refer to the operator using the MAAT Funeral Services brand. The operator's full legal name and business mailing address have not yet been supplied and must be added before public launch. This policy does not assert ownership by or affiliation with MAAT K12, Soreey LLC, or another organization.
Service areas are coming soon. Submitting an inquiry does not confirm coverage, a booking, a contract, or payment. Actual funeral-service records, authorizations, arrangements, and regulated records require a separate, jurisdiction-specific records schedule before those services are operated.
2. Information collected and why
| Information | Source | Purpose |
|---|---|---|
| Name and email address; optional phone number | Your inquiry | Respond to you and coordinate requested follow-up |
| Optional city, state/region, and ZIP/postal code | Your inquiry | Understand where services are requested and discuss availability; not a confirmation of coverage |
| Service interest, preferred contact method, and message | Your inquiry | Understand the request and respond appropriately |
| Inquiry reference, duplicate-submission identifier, creation/update timestamps, and contact-consent timestamp | Website system | Store the inquiry, avoid duplicate submissions, and record its handling |
| Lead status, assigned staff member, follow-up date, internal notes, and activity history | Authorized staff and system | Coordinate customer service and maintain accountability |
| Email recipient, subject, message body, delivery status, attempt count, timestamps, and failure category | Staff and outgoing mail system | Send requested replies, notify staff, and troubleshoot delivery |
| Staff name, email, password hash, role, account status, session-token hash, and anti-forgery token | Account administrator, staff, and authentication system | Authenticate staff and control access |
| IP address and request counters; account-email hash for login throttling | Your connection and security system | Limit spam and abusive login attempts |
| Technical request information such as IP address, requested URL, user agent, timestamp, and response status | Web server, VPS, reverse proxy, and configured providers | Deliver the website, investigate errors, and maintain security |
The inquiry database does not intentionally request a street address, date of birth, government identifier, payment-card details, medical records, or information about children. Free-text messages can contain sensitive personal information if you enter it. Please do not include medical, financial, identity, or detailed religious information, or documents about a deceased person, in the inquiry form. We will request only necessary additional information through an appropriate process if arrangements proceed.
Do not submit another living person's information unless you are authorized to do so. An inquiry does not authorize general marketing, publication of a memorial, or disclosure to unrelated businesses.
3. The planning worksheet
The planning worksheet is separate from the inquiry form. Its answers remain in the current page's browser memory and are not submitted to MAAT by the worksheet code. Leaving or reloading the page clears that memory. If you download the worksheet, the file remains on your device until you delete it. Your device, browser, or backup services may retain copies outside MAAT's control. Sharing a downloaded worksheet is your choice.
4. How information is used
Information is used to answer inquiries, assess possible service availability, coordinate staff follow-up, send service-related replies, maintain the site, prevent misuse, and address privacy or legal requests. The current build does not use inquiry information for advertising, automated eligibility decisions, AI model training, or public memorial listings.
The contact checkbox authorizes responding to the inquiry. It is not blanket consent to marketing or every form of processing. Where a particular legal basis or separate consent is required, that requirement must be assessed for the service and location involved.
5. Access and disclosures
Authorized MAAT staff can access the care desk. In the current build, all active staff accounts can view all inquiries; assignment does not restrict visibility. Accounts should therefore be issued only to people whose duties require that access. Administrators can create staff accounts; server administrators can reset passwords or disable accounts.
Hosting and infrastructure providers process information needed to operate the service. The package is designed for a Hostinger VPS, but actual deployment, hosting region, and the operator's provider arrangements have not been verified. If SMTP is configured, the selected email provider processes outgoing message content and delivery information. Mail copies may also remain in recipient inboxes, staff mailboxes, or provider systems. Those copies must be included in operational retention procedures.
Staff new-lead notifications contain the inquiry reference and a staff-desk link, not the original message body. Staff replies contain the message the staff member writes. Email is not guaranteed to be confidential or delivered, and mail-server acceptance is not proof that a message was read.
Information may also be disclosed when legally required, to protect legitimate rights or safety, or to professional advisers who need it for those purposes. Any new service provider or business transfer must be assessed for appropriate privacy protections and required notice. The current inquiry workflow does not automatically send customer details to funeral partners or confirm third-party arrangements.
6. Cookies, fonts, and tracking
The public inquiry form does not require a visitor account and the application does not set advertising cookies. Staff sign-in uses the essential maat_session cookie, configured to expire after eight hours. The production configuration marks it HttpOnly, SameSite=Strict, and Secure; HTTPS must be working for that configuration to function correctly. Signing out invalidates the server session.
The site requests fonts from Google Fonts. These requests can disclose connection information, including the IP address and browser request headers, to Google. See Google's privacy information at https://policies.google.com/privacy and its Fonts privacy explanation at https://developers.google.com/fonts/faq/privacy. Font-provider retention is governed by that provider's practices, not MAAT's proposed database schedule.
No advertising, analytics, social-media tracking, or cross-site behavioral tracking scripts have been added to this build. It does not vary behavior in response to the older Do Not Track signal because that tracking is not implemented. The current build has no personal-information sale or cross-context advertising-sharing mechanism, so Global Privacy Control does not change its behavior. Reassess these statements and applicable consent/opt-out requirements before adding trackers or new integrations.
7. Retention schedule
The following periods are proposed operational limits, not statutory retention rules or a claim that automatic deletion is active. Review records monthly, document exceptions, and adopt these limits only after confirming applicable requirements and implementing procedures for the database, email systems, logs, and backups.
| Record category | Proposed retention rule | Disposal or review |
|---|---|---|
| Inquiry that does not become a service arrangement, including notes and ordinary correspondence | 12 months after the last meaningful customer-service activity | Review and delete or irreversibly de-identify unless a documented exception applies; a routine internal status change alone must not extend retention |
| Open inquiry with a continuing purpose | Review at least every 6 months | Record why it remains necessary and set the next review date; no indefinite retention merely because status is open |
| Inquiry that becomes an actual service arrangement | Transfer only necessary information into the separately approved service-record system | Apply the relevant jurisdiction and record-type schedule; do not use the 12-month inquiry period to delete legally required funeral records |
| Clearly identified spam or irrelevant inquiry | Up to 30 days after classification | Delete after checking for a legitimate request or security investigation |
| Local outgoing-mail queue and mail history | No longer than the associated inquiry; review unsent/uncertain messages within 7 days | Cancel stale queued mail before deleting an inquiry; review provider/mailbox copies separately |
| Raw operational access and error logs | Target maximum 30 days | Configure and verify rotation/deletion on every relevant host and provider; preserve only necessary incident excerpts under a documented exception |
| Temporary rate-limit entries | Enforcement windows: 15 minutes for login attempts and 1 hour for inquiry attempts | Currently removed on a later rate-limited request after expiration; daily cleanup is proposed so stale rows do not linger on an idle site |
| Staff sessions | Eight-hour validity; invalidate on logout, password reset, or account disablement | Expired database rows are currently cleaned during later successful login; daily physical cleanup is proposed |
| Disabled staff account profile | Revoke access immediately; review within 30 days | Remove unnecessary profile and credential information, while preserving minimal attribution where genuinely needed for a retained record |
| Privacy-request record | 24 months after closure, subject to applicable law | Keep only request type, necessary verification/outcome evidence, dates, and any justified exception; do not routinely retain identity-document copies |
| Routine backup copies | Rolling 35-day target | Expire backup copies securely; apply pending deletions again after a restore before ordinary use resumes |
| Documented dispute, legal hold, or security investigation | Only as long as required for the specific obligation or purpose | Restrict access, record the basis and review date, and resume normal disposal when the exception ends |
The current code stores inquiries, notes, and mail records until an operator removes them. It does not enforce the proposed 12-month, 30-day, 24-month, or 35-day periods. Existing backups are manually created and have no automatic expiry in the delivered configuration. There is no live retention service, customer self-service deletion screen, or automatic purge job yet.
8. Deletion and backups
When a valid deletion request or retention deadline applies, the operator should locate the inquiry, linked activity/notes, local email queue/history, relevant mailbox/provider copies, and any unnecessary exports. Pause pending messages so deleted requests do not generate later replies. Retain only information subject to a valid exception, and explain the exception where appropriate.
Routine backups may retain a removed record until the backup expires. Restrict their use to recovery and security needs. Maintain a minimal, access-controlled deletion record so a restoration does not silently reactivate removed information. Do not claim irreversible erasure based only on deleting a SQLite row: database files, journal files, snapshots, disks, and provider storage can retain remnants. Select and verify disposal methods appropriate to the storage system.
9. Your choices and privacy requests
Email Info@Maatfuneralservices.com with the subject Privacy request. State whether you want to access or obtain a copy of information, correct it, request deletion, stop optional follow-up, or ask a question. Include the inquiry reference if available. Do not send passwords, payment information, medical records, or a government-ID copy in the initial email.
MAAT should verify requests proportionately, usually by checking the original contact channel and inquiry reference. Additional verification may be needed when there is a reasonable risk of disclosing another person's information. An authorized agent may be asked for evidence of authority. Do not disclose a record merely because someone knows a name or a reference number.
Available rights and exceptions depend on applicable law. Where provided by law, these can include access, correction, deletion, portability, limits on particular processing, an authorized-agent process, and appeal of a refusal. You may ask why a request was declined and request reconsideration at the same address. Applicable regulator or complaint rights remain available. Exercising a privacy right should not result in unlawful discrimination.
The proposed operational goal is to acknowledge requests within 10 business days and respond within 30 calendar days, or sooner where law requires. These are proposed service targets, not a statement that a particular law applies. If an extension is permitted and needed, provide the reason and expected completion date within the applicable deadline.
Withdrawing permission for optional contact does not necessarily require deletion of information that must be kept for a legal obligation or a legitimate, documented dispute. Explain what is retained and why, where appropriate. The contact mailbox and request-handling procedure must be verified before launch.
10. California and other locations
The site's service areas have not yet been announced. This policy does not assume that the CCPA/CPRA, GDPR, or every other privacy law applies to MAAT. Applicability depends on facts such as the operator, activities, locations, and statutory criteria. If a law applies, the operator must provide its required notices, rights, response procedures, and any additional request channels before collecting covered information.
The current build is not configured to sell personal information or share it for cross-context behavioral advertising. If this changes, update the notice and implement applicable choice mechanisms before starting that activity. The draft describes the current build, not a verified statement about the operator's historical practices during the preceding 12 months.
11. Children and sensitive matters
The service inquiry form is intended for adults arranging or exploring services. It is not designed to solicit information directly from children under 13. If you believe a child submitted personal information, contact the privacy address so the operator can review and appropriately remove it, subject to necessary legal exceptions. Do not treat this notice as an age-verification control; none is implemented.
A funeral-related inquiry may concern sensitive family circumstances. The site does not provide a medical-record portal and does not claim HIPAA certification or compliance. Determine any applicable duties before collecting health information or regulated service records through a new workflow.
12. Security and international processing
The build includes password hashing, server-side sessions, role checks for administrator functions, anti-forgery checks, and rate limiting. Production HTTPS, staff access review, server updates, mailbox protections, backups, and incident-response procedures remain deployment and operational responsibilities. The SQLite file is not encrypted by the application; do not describe it as encrypted at rest unless an actual storage control has been configured and verified. No system can guarantee perfect security.
Hosting and email processing locations depend on the selected providers and configuration. No data-residency promise or international transfer mechanism has been verified. Confirm provider locations and any required transfer arrangements before serving a jurisdiction that requires them.
13. Policy changes and contact
When adopted, publish an effective date and the current version on this page. For material changes, provide a prominent website notice and, where required or appropriate, direct notice before the changed practice begins. Obtain consent where required rather than treating an amended notice as retroactive authorization. Keep prior versions in an internal policy register.
Questions and requests: Info@Maatfuneralservices.com.
Legal operator name and mailing address: not yet supplied; required before public launch.