Mastodon Municipal Draft Municipal Data and Security Addendum

Draft for attorney review — not final terms

Draft date: October 10, 2026

This proposed addendum describes data-handling and security provisions for Mastodon Municipal, a multi-tenant municipal communications, operations, scheduling, and documents platform. It is a review placeholder, not an operative contract, security attestation, or statement that every described capability exists today. Viewing this page, registering, or using the platform does not accept this draft. No signatures or acceptance are requested. Binding obligations would require finalized terms and an authorized municipal contracting process.

1. Parties and scope

The proposed provider is [TO BE CONFIRMED: operator legal entity], at [TO BE CONFIRMED: legal address] (“Provider”). The customer is [TO BE CONFIRMED: municipality or other authorized public body and address] (“Customer”). The governing service agreement and covered tenant accounts are [TO BE CONFIRMED].

“Customer Data” would include records and content submitted to, stored in, or generated for Customer through the covered services, together with associated metadata. The final schedule must distinguish Customer Data from Provider’s separate business records and identify overlapping records that remain subject to Customer’s access, preservation, or disclosure duties.

2. Ownership and permitted processing

Customer would retain ownership and control of its records, subject to applicable law and third-party rights. Provider would receive only the rights needed to deliver, support, secure, and maintain the agreed services and follow Customer’s documented lawful instructions. No transfer of ownership is proposed.

Provider would limit access to personnel and approved service providers with a service-related need. Any proposed secondary use, including analytics, advertising, or model training, must be separately identified and reviewed before inclusion in final terms; this draft grants no such permission.

3. Tenant authorization and municipal authority

Customer would designate administrators and authorized users, manage their permissions, and notify Provider when access should end. Provider would maintain reasonable account and tenant-access safeguards under the verified security schedule.

An invitation, verified email domain, account role, or administrator designation would establish only the applicable platform permissions. It would not establish authority to bind the municipality, waive legal rights, approve spending, authorize record destruction, or override procurement requirements. Contracting authority and authorized instruction contacts are [TO BE CONFIRMED].

4. Processing schedule to complete

Before activation of final terms, the parties would complete a schedule covering:

• People: municipal employees, officials, contractors, and other individuals whose information Customer lawfully includes; actual categories [TO BE CONFIRMED]
• Data: account and contact information, roles, communications, schedules, operational records, documents, attachments, associated metadata, and relevant activity or support records; actual fields [TO BE CONFIRMED]
• Purposes and operations: account administration, authorized collaboration, storage, retrieval, scheduling, support, security, export, and lawful preservation or deletion
• Duration and locations: service period, export arrangements, retention requirements, processing regions, support-access locations, and backup locations [TO BE CONFIRMED]
• Sensitive or regulated information: permitted categories, exclusions, additional agreements, and safeguards [TO BE CONFIRMED]

This schedule must not imply approval for health, criminal-justice, financial, child-related, or other specially regulated records before the applicable requirements and technical suitability have been reviewed.

5. Confidentiality and public records

Provider would protect nonpublic Customer Data from unauthorized use or disclosure and bind authorized personnel and service providers to appropriate confidentiality obligations. These obligations would permit disclosures required by law, valid legal process, or Customer’s lawful instructions.

Customer would determine its public-records obligations, applicable exemptions, redactions, and disclosure decisions. Hosting a record with Provider would not itself make the record confidential or exempt. Records held by a contractor may remain subject to Illinois FOIA where its statutory conditions apply.

Provider would reasonably support retrieval, preservation, and record integrity for Customer’s responses. Provider would refer requests concerning Customer’s records to Customer where legally appropriate and notify Customer of compelled disclosure unless prohibited. Neither party would promise that every platform record is exempt from disclosure.

6. Proposed security safeguards

Provider would implement and maintain reasonable administrative, technical, and organizational safeguards appropriate to the records and risks, including protection against unauthorized access, acquisition, destruction, use, modification, and disclosure.

A verified security schedule must identify implemented controls, responsible parties, and material limitations. Items to validate include tenant isolation, access administration, encryption configuration, logging, vulnerability management, backup and restoration practices, personnel access, and incident response. Listing these items does not attest that particular controls, test results, or recovery capabilities exist.

This draft makes no SOC 2, HIPAA, CJIS, ADA-certification, end-to-end-encryption, or zero-access claim. Any assurance would need its own verified evidence and precisely defined scope.

7. Service providers and processing locations

The provider inventory supplied for this draft identifies Supabase and Vercel as current providers. Resend is selected but not live. Stripe is planned or test-only; production payment processing is not represented as active.

For each provider, the contracting legal entity, function, information accessed, processing and support locations, downstream providers, and applicable agreements are [TO BE CONFIRMED]. No United States-only residency commitment is made.

Proposed downstream obligations would require appropriate confidentiality, reasonable security, limited processing purposes, and relevant incident and preservation cooperation. The subprocessor approval or notification procedure, change-notice period, objection process, and contractual allocation of responsibility remain [TO BE CONFIRMED].

8. Security incidents and notification

Provider would investigate suspected unauthorized access to or compromise of Customer Data, take reasonable containment and remediation steps, preserve relevant evidence, and cooperate with Customer. Notification would follow applicable statutory timing and requirements.

Where Illinois PIPA’s processor-notification provision applies, Provider must notify the data owner or licensee immediately following discovery of a breach when covered personal information was, or is reasonably believed to have been, acquired without authorization. An incomplete investigation would not justify withholding legally required initial notice.

Updates would describe known scope, affected information, response measures, and material developments. Each party would remain responsible for its own legal notice duties and coordinate where appropriate. Incident contacts, delivery channels, assistance scope, and cost allocation are [TO BE CONFIRMED]; no separate hourly notification SLA is proposed here.

9. Export after cancellation

Customer would have a 90-day full-data export entitlement after cancellation. The event starting that period is [TO BE CONFIRMED: cancellation request, effective termination, or another expressly agreed event]. It must be resolved before final terms become operative.

The export specification must define included content, attachments, metadata, relationships, available history, formats, delivery method, identity checks, completion process, and any expressly identified exclusions. These details and implementation tests are [TO BE CONFIRMED]. Scope must be settled before activation so “full-data export” has a clear, usable meaning.

Expiration of this period would not authorize automatic deletion on day 91 or promise indefinite free hosting. Post-period access, preservation, and transition arrangements remain [TO BE CONFIRMED], subject to the following safeguards.

10. Retention holds and deletion

Provider would retain and dispose of Customer records only according to lawful Customer instructions, applicable records schedules, and legal obligations. Customer would identify required retention periods and obtain records-commission authorization where applicable. Cancellation or a user’s deletion request alone would not authorize unlawful destruction.

Litigation holds, preservation duties, and other applicable legal restrictions would override routine deletion. The parties would document hold instructions and release authority. Backup retention, deletion timing, restored-data handling, and deletion verification are [TO BE CONFIRMED] and require technical validation. This draft does not promise untested selective deletion or restoration capabilities.

11. Assistance review and precedence

Provider would offer proportionate assistance with lawful records requests, security reviews, incident investigations, and agreed audits while protecting other tenants’ information and system security. Evidence, procedures, response targets, frequency, scope, and costs are [TO BE CONFIRMED].

Counsel review required: confirm party identities and municipal authority; complete processing, security, provider, export, and retention schedules; review insurance, liability, remedies, and procurement requirements; and establish precedence among the final service agreement, this addendum, municipal requirements, and other policies. No final order of precedence is proposed by this placeholder.

Draft for attorney review — not final terms. All bracketed items remain open.