Privacy policy

Last updated [DATE - SET AT PUBLICATION]

This policy explains what Marshal collects, why, who else sees it, how long we keep it, and what you can ask us to do about it. It is written to match what the product actually does. Where a practice is narrower or broader than people usually assume, we say so plainly.

1. Who we are

[MARSHAL LEGAL ENTITY NAME], [COMPANY REGISTERED ADDRESS - COMPANY TO CONFIRM], operates marshalcloud.com.

• For the account details of the people who sign in to Marshal, we act as the controller.
• For the data we read from your cloud accounts and your tracked computers, we act as a processor on your instructions. Your organization is the controller. The data processing addendum governs that relationship.
• Privacy questions: [PRIVACY CONTACT EMAIL]. Security reports: [SECURITY CONTACT EMAIL]. [DATA PROTECTION OFFICER OR EU/UK REPRESENTATIVE - COMPANY TO CONFIRM WHETHER ONE IS REQUIRED.]

2. What we collect

2.1 Account data

For each person with a login: email address, name, a password hash (we never store the password itself; it is hashed with PBKDF2-HMAC-SHA256 at 600,000 iterations with a per-user salt), an optional avatar image or image URL, the role they hold in each organization, whether they have verified their email, and when the account was created. For each organization: its name, plan, type, and optional branding (company name, logo URL, colour).

2.2 Account security log

We record account security events for each user: the event (sign-in, password change, profile update), a short description, the IP address the event came from, and the time. This is how you and we can see whether an account has been misused.

2.3 Cloud data

When you connect a cloud account we read:

• Billing and usage records. Cost line items with the billing period, service, region, sub-account, resource identifier, charge description, usage quantity, cost figures, and the tags you have applied to your own resources.
• Resource configuration. The inventory needed to draw your architecture and find waste and risk: instance types, disk sizes and encryption state, database engines and versions, availability zones, subnet ranges and whether a subnet is public, private and public IP addresses, and security group rules including protocols, ports, and the IP ranges allowed through them.
• Utilization metrics. CPU, memory, and network figures used to judge whether a resource is oversized or idle.
• Change records. Write events from your cloud audit trail: what action was taken, on which resource, when, and the identity that took it. That identity is usually a person or a role, so this category can identify individuals in your organization.
• Kubernetes usage, if you install our cluster agent: node, namespace, pod, and workload names with their CPU and memory requests and usage. No pod logs, no secrets, no container filesystems.
• Data from tools you connect, currently Datadog and Sentry: the events they expose to the token you give us.

What we never read. We do not read the contents of your databases, your object storage, your application data, your logs, or your backups. The one exception is narrow and worth stating exactly: to load your billing data we download the cost export files that AWS itself writes into a bucket in your account, restricted to files under the billing export prefix. Those files are generated by AWS, not by your applications.

2.4 Credentials

The default connection is a cross-account role plus a secret external ID, so we hold no long-lived keys. Where a key or token is used instead (an access key, an AWS IAM Identity Center token, a Datadog or Sentry token, a webhook URL), it is encrypted at rest and is never displayed in the product, never returned by our API, and never written to our logs. Webhook addresses appear in listings with only the host shown.

2.5 Monitoring results

For each check of a website, endpoint, TCP port, DNS name, or heartbeat we store: the organization, the monitor, the time, whether it succeeded, the HTTP status code, the response time, and any error text. Errors are truncated, and URL credentials, query strings, and paths are stripped from error text before it is used in any AI feature, because those can carry tokens.

2.6 Device telemetry

If you choose to install the Marshal device reporter on a computer, that computer sends us a snapshot roughly every ten minutes. The snapshot contains exactly these fields, and nothing else:

• operating system family and version string
• hostname
• how long the computer has been powered on
• total disk size, disk used, and percentage used
• total memory and processor count
• the number of pending operating system updates
• whether the built-in firewall is on
• whether disk encryption is on

The reporter does not collect: usernames or who is signed in, installed applications, running processes, browsing history, files or file names, screenshots, keystrokes, location, serial numbers, MAC addresses, or the computer's IP address. It only reads. It never changes anything on the computer, and its source is visible to you before you install it.

If you install the reporter on computers used by your staff, this is employee monitoring, and you are responsible for it. Marshal is your processor for this data. You must tell the people who use those computers what is collected, and you must have a lawful basis for doing so. Depending on where they live, that can also require a consultation with a works council or employee representatives, a notice, or an impact assessment. We do not do that for you and we cannot verify that you have done it.

2.7 Product and support data

Records of the actions you propose and approve (who proposed, who approved, each step, and the rollback record), alerts and their delivery results, recommendations, and any messages you send us for support. Conversations with the AI assistant are stored so the thread can continue.

2.8 Cookies and tracking

[COOKIE AND ANALYTICS DISCLOSURE - COMPANY TO CONFIRM WHAT THE MARKETING SITE AND APP ACTUALLY SET.] The application itself keeps your sign-in token in your browser's local storage rather than in a cookie.

3. Why we use it

• To provide the service you asked for: showing spend, monitoring, security findings, recommendations, and carrying out changes you approve.
• To send you alerts, reports, and service messages through the channels you configure.
• To keep accounts and infrastructure secure, detect abuse, and enforce plan and rate limits.
• To bill you and keep financial records.
• To support you when you ask for help.
• To improve the service using aggregated statistics that do not identify you or any individual.

We do not sell personal data, we do not share it for cross-context behavioural advertising, and we do not use your data to train our own or anyone else's models.

4. Legal bases

[GDPR AND UK GDPR APPLICABILITY - COMPANY TO CONFIRM.] Where those laws apply, our intended bases are:

• Contract for account data and for delivering the service you subscribed to.
• Legitimate interests for security logging, abuse prevention, and service improvement, balanced against the rights of the people involved.
• Legal obligation for tax and accounting records.
• For cloud and device data we are the processor, so the customer chooses and documents the basis. [CUSTOMER-FACING GUIDANCE ON THE BASIS FOR DEVICE MONITORING - COUNSEL TO ADVISE.]

5. Artificial intelligence

Marshal uses AI to explain your data in plain language, summarize incidents, draft postmortems, and answer questions. To do that, excerpts of your data are sent to two AI providers: Anthropic and OpenAI. What is sent:

• your question, and the recent turns of that conversation;
• cost totals grouped by service, region, account, or period;
• recommendation titles, dollar estimates, and confidence levels;
• resource identifiers, names, types, regions, and states;
• monitor names, states, response times, certificate and domain expiry dates, and redacted error text;
• incident titles and times;
• security finding titles, severities, and the resource they concern;
• change records including the identity that made a change;
• your organization's plan and the number of connected accounts.

What is never sent: your cloud credentials, any secret, and any device telemetry. The AI has no ability to change your infrastructure. Every value it receives is length-limited and stripped of control characters, and resource configuration used for search is limited to an allowlist of shape and size fields, never addresses, IP ranges, URLs, or free-form descriptions.

Anthropic and OpenAI process this data to return a response to us. Per those providers' published API data-use commitments, data submitted through their business APIs is not used to train their models. Those commitments are theirs, not ours, and they can change them. [CONFIRM THE CURRENT COMMITMENTS AND WHETHER ZERO-DATA-RETENTION TERMS HAVE BEEN SIGNED WITH EACH PROVIDER - COMPANY TO CONFIRM. Marshal's code does not currently set any zero-retention flag on these API calls.]

6. Who else sees your data

• Subprocessors. The current list, what each one is for, and what it receives, is at marshalcloud.com/legal/subprocessors.
• Our staff. Some Marshal personnel hold a platform role that can read across organizations to support you and keep the service running. A platform reliability role is read-only. Access is role-based and administrative actions are recorded.
• Where you send it. If you configure Slack, a webhook, or an email recipient, alert titles and bodies go there. Uptime alerts can include the monitored address and the error text; device alerts include the computer's name and the issue, for example that its disk is 92% full.
• An agency you link. If you link a DevOps agency organization to yours, its admins can act in your organization up to the role you granted. You control that link.
• Legal. We may disclose data where the law requires it, and we will tell you unless we are prohibited from doing so.
• Corporate change. If we are acquired or merged, data may transfer with the business, subject to this policy.

7. How long we keep it

8. Your rights

Depending on where you live you may have the right to access, correct, delete, restrict, object to, or receive a portable copy of your personal data, and to complain to a supervisory authority. Write to [PRIVACY CONTACT EMAIL]. We will respond within [RESPONSE TIME - COMPANY TO CONFIRM, TYPICALLY ONE MONTH]. If you are an employee whose work computer is tracked, contact your employer first: they decide what is collected, and we will refer your request to them.

What we can do today, stated accurately:

• Access and correction. You can see and edit your own profile in the product. Ask us for anything else.
• Deletion. Deleting an organization is implemented and erases its rows from our primary database, deletes its billing, usage, and uptime rows from the analytics store, and clears its cached data. The analytics and cache steps are best effort, and the system reports whether each actually succeeded so that a partial erasure is never mistaken for a complete one; where a step fails we repeat it. Deleting an organization does not delete a person's login record or their account security log, because those belong to the person and can span several organizations. Deleting a user is a separate operation, and we will do it on request. Both operations are performed by our staff, not from a button in the product.
• Portability. Partial today. You can export cost breakdowns and security control evidence as CSV from the product, and share a report link. A single complete export of everything an organization holds is not built yet. [FULL EXPORT - PRODUCT TO BUILD; UNTIL THEN WE PRODUCE IT MANUALLY ON REQUEST.]
• Ending our access. You do not need us for this. Delete the role you installed in your cloud account, uninstall the cluster agent, or remove a computer, and the access stops at that moment.

9. How we protect it

• Cloud credentials and connector tokens are encrypted at rest and never returned by our API or written to logs.
• Traffic is served over HTTPS. Outbound webhooks must be HTTPS to a public address, and the connection is pinned to a validated address to stop redirection at internal systems.
• Every request is checked against the caller's membership of the organization, and every record fetched by ID is checked against the caller's organization through a single enforcement point.
• Passwords are hashed with PBKDF2-HMAC-SHA256 at 600,000 iterations. Sign-in tokens expire, and a user can be signed out everywhere at once.
• Infrastructure changes come only from a fixed catalog, require a human approval by a user with the right role, take a snapshot before destroying anything, and are recorded step by step.
• Rate limits and a daily AI usage cap protect the service from abuse.
• Open items we choose to disclose rather than hide: sign-in tokens are held in browser local storage rather than a hardened cookie, credential encryption uses an application key rather than a hardware key management service, and email addresses are not yet verified before use. These are tracked and are being addressed. [SECURITY PROGRAM MATURITY CLAIMS AND ANY CERTIFICATION STATEMENT - COMPANY TO CONFIRM. DO NOT CLAIM SOC 2 UNTIL AN AUDIT IS COMPLETE.]

10. Where your data is

[HOSTING LOCATIONS AND REGIONS - COMPANY TO CONFIRM.] Our subprocessors may process data in [COUNTRIES - COMPANY TO CONFIRM], including the United States. Where a transfer leaves the European Economic Area or the United Kingdom, we rely on the European Commission's standard contractual clauses and the UK addendum. [MODULE SELECTION AND TRANSFER IMPACT ASSESSMENT - COUNSEL TO CONFIRM.] There is no data residency option today: we cannot promise to keep your data in a particular region.

11. Children

Marshal is a business tool. It is not directed at children, and we do not knowingly collect personal data from anyone under [MINIMUM AGE - COMPANY TO CONFIRM]. If you believe a child has given us data, write to [PRIVACY CONTACT EMAIL] and we will delete it.

12. Changes to this policy

If we change this policy in a way that materially affects you, we will email your organization's owners and show a notice in the product at least [PRIVACY CHANGE NOTICE PERIOD - COMPANY TO CONFIRM] before it takes effect. The date at the top always shows the current version.