Security at Morton Command Center

Security isn’t a checkbox for MortonApps LLC: every Morton Command Center deployment touches your tenants’ ticket data, billing records, and security alerts. The platform is designed around three principles: your data stays in your tools, least-privilege access by default, and edge-deployed infrastructure with each customer’s data kept apart.

This page summarizes the technical and operational controls we use. For per-customer specifics, see your agreement with us, including a Data Processing Addendum (DPA) where one is signed.

Architecture & data residency

Morton Command Center is built on Cloudflare’s global edge network. Each customer instance is deployed as its own Cloudflare Pages project with its own dedicated D1 database, KV namespace, R2 bucket, and Workers, all created fresh when your deployment is provisioned. Isolation is structural rather than a permission setting: the application resolves every query through a single database binding, and that binding points only at your database. There is no shared operational database holding more than one customer’s records, and no cross-tenant query path to misconfigure.

Four deliberate exceptions, stated plainly:

• Email sending. Every instance sends its email through Morton Mail, a sending service MortonApps runs for all its products. It keeps each message’s content, recipients and attachments for 30 days after sending, then deletes them. After that it keeps a sending record (when the message was sent, how many people it went to, how that turned out, and the sender’s name and address), which for some messages also includes recipients’ addresses. Addresses that bounce or report a message as spam go on a do-not-send list that all our products share, which keeps the address and the reason until the entry is lifted, so none of our products emails them again. Each instance uses its own key, and a key can reach only its own messages; the do-not-send list is the one thing every key can check and update.
• Bug reports. If a user submits an in-app bug report, that report is sent to a central feedback service shared across MortonApps products. It carries the submitting user’s email, the page they were on, and (if they choose to attach one) a screenshot, which may show whatever was on their screen at the time. Nothing is sent unless a person files a report.
• AI tools. We use Claude, from Anthropic, to build, support, and maintain the platform. It reads bug reports and support emails and, when we troubleshoot an instance, that instance’s data, and its replies reach us through Telegram, which can quote that data. Notes from that work stay on our working computer, which is backed up to Google Drive. We use it under Anthropic’s consumer terms, not a data processing agreement; our Privacy Policy says what Anthropic keeps and for how long.
• Backups. Encrypted backups of every instance’s database, and of the Morton Mail and feedback service databases, are stored together in our backup storage (Amazon S3 and Cloudflare R2), along with copies of the files those services and each instance store (attachments and bug-report screenshots). A backup keeps what was stored when it was taken, so content blanked or deleted later can remain in a backup until that backup expires or, for a file, until we remove its copy; our Privacy Policy gives the schedule.

Your business data stays in your tools. Morton Command reads from your existing PSA, RMM, accounting system, and security stack via API and renders unified views. Records created in Morton Command itself, such as native timecards and contracts, live in your instance’s database; you can export them before we delete them when you leave. Records in your other tools stay where they are.

Encryption

• In transit: All traffic to and from the platform uses TLS 1.2 or higher. HTTP requests are automatically upgraded to HTTPS at the edge. HSTS is enforced.
• At rest: All persistent storage (your Cloudflare D1 database, which holds your operational records, plus the KV namespace used for tokens and short-lived caches and the R2 bucket used for file attachments) is encrypted at rest by the platform provider using industry-standard algorithms. Per-agent secrets (vendor API tokens, OAuth refresh tokens) are additionally encrypted with a tenant-specific key before being stored.
• Vendor credentials: When we connect a third-party tool (your PSA, RMM, accounting system, phone system, or security stack), the credentials are stored as encrypted secrets and used only to call that vendor on your behalf. They are never logged or returned in client-facing responses. Every integration is custom-built to fit your exact stack as part of your engagement: because the platform is API-driven, if a tool has an API we build the adapter for it (your PSA, RMM, accounting system (QuickBooks, Xero, Sage, or anything with an API), phone system, or security stack) and it is built and secured for your environment, every time.

Authentication & access control

• Identity: Authentication is handled by Clerk, a SOC 2 Type II certified identity provider. Each Morton Command instance runs its own Clerk application with restricted-mode sign-up: only pre-provisioned email addresses can sign in.
• Multi-factor authentication: Supported via Clerk for all users. Enforceable per-organization.
• Single sign-on: SAML and OIDC SSO available for customers with their own identity provider.
• Role-based access control: Built-in roles (Administrator, Manager, Finance, Technician, Sales, Read-Only) gate access to every page and API endpoint. Per-permission overrides are configurable per user.
• Per-company scoping: Technicians can be restricted to a subset of companies and groups. Restrictions are enforced server-side, not just hidden in the UI.
• Cloudflare Access integration: For deployments that require an additional pre-authentication layer (e.g. corporate IP allowlisting, hardware key enforcement), Cloudflare Access can be enabled in front of the entire dashboard.

Audit logging

Every administrative action (sign-in, role change, configuration update, integration connect/disconnect, ticket modification) is recorded to a tenant-scoped audit log and made available to Administrators through the dashboard. The in-dashboard log retains roughly the most recent 30 days of activity. Customers can request longer retention or export under their agreement with us.

Infrastructure security

• Edge-deployed: The platform runs on Cloudflare’s global edge network with built-in DDoS protection, WAF, and bot management. There is no traditional origin server to attack.
• Network isolation: Each customer instance has its own D1 database, KV namespace, R2 bucket, and Workers project. Cross-tenant access isn't a permission that could be misconfigured: those resources aren't shared between deployments. The shared services that handle customer data are the four exceptions listed above.
• No customer-side agent: Morton Command does not require an agent installed on customer endpoints or behind your firewall. All connectivity is outbound from the platform to your existing vendor APIs over TLS.
• Content Security Policy: Strict CSP headers are applied to every dashboard response, blocking inline scripts from untrusted origins.
• Secrets management: Build-time and runtime secrets are stored as encrypted Cloudflare Pages environment variables. Per-agent secrets (vendor OAuth tokens, personal API keys) are encrypted with a tenant-specific key before storage and only decrypted at the moment of an outbound API call on the agent’s behalf.

Vendor & subprocessor management

We use a deliberately small set of carefully chosen subprocessors. The current list, scope, and locations are published in our Privacy Policy. Notable certifications:

• Cloudflare: SOC 2 Type II, ISO 27001, ISO 27018, PCI DSS Level 1
• Clerk: SOC 2 Type II
• Amazon Web Services (SES, Lambda, S3): SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, PCI DSS, HIPAA-eligible

We update the subprocessor list in our Privacy Policy whenever it changes.

Software development lifecycle

• Code review: All changes are reviewed before deployment. Production deploys are auditable through git history.
• Dependency hygiene: Third-party dependencies are pinned and regularly reviewed for known vulnerabilities.
• Testing: Critical paths (authentication, billing logic, data isolation) are exercised before each release.
• Edge deploys: Releases are deployed atomically to Cloudflare’s edge with versioned cache-busting filenames. Stale-tab detection ensures users pick up new versions on next page load without disrupting active sessions.

Incident response

If we detect or are notified of a security incident affecting customer data, we will:

1. Contain and investigate the incident promptly
2. Notify affected customers without undue delay (and within the timelines applicable law and any DPA we have signed with you require)
3. Provide a written post-incident summary describing the cause, impact, and remediation
4. Implement corrective measures to reduce the risk of recurrence

Customers can report a suspected vulnerability or incident at any time to [email protected].

Responsible disclosure

We welcome reports from security researchers. If you believe you’ve found a vulnerability in Morton Command Center or the website, please email [email protected] with the details and a way to reproduce. We commit to:

• Acknowledging your report within 5 business days
• Investigating in good faith
• Not pursuing legal action against researchers who report in good faith and avoid privacy violations, service disruption, or destruction of data
• Crediting researchers (with permission) in a future advisory or hall of fame

Compliance posture

Morton Command Center runs entirely on infrastructure that is independently certified (Cloudflare, Clerk and AWS are all SOC 2 Type II at minimum), so the controls at the infrastructure layer are covered by their audits. A certification belongs to the provider that earned it, though, and isn’t something we can inherit: MortonApps itself is not yet SOC 2 certified. Direct certification is planned as we grow. In the interim we complete customer security questionnaires on request.

If you work in a regulated industry (healthcare, financial services), tell us your requirements before you sign, and we will tell you in writing which ones we can meet.

Customer responsibilities

Security is a shared responsibility. Your part includes:

• Provisioning user accounts only for personnel who need access
• Enforcing multi-factor authentication for your team
• Choosing strong, role-appropriate scope for technician accounts
• Rotating any vendor credentials you suspect of being compromised
• Notifying us promptly of personnel departures so we can revoke access
• Following the acceptable-use rules in our Terms of Service

Questions or due diligence

For prospective customers conducting security due diligence (including completing a security questionnaire, reviewing our agreements, or arranging a call with our team), please email [email protected].

Please don’t email us confidential or sensitive information, such as passwords, account credentials or personal records. If you send it anyway, we’ll keep it confidential and delete it when we no longer need it.