Skip to content

Data processing addendum

Last revised 5 October 2026. In effect from 22 September 2026.

This addendum forms part of the terms of service between DEVINSEC PVT. LTD (“DevInSec”), Kathmandu, Nepal, and the customer (“Customer”). MarshalCloud is a product of DEVINSEC; where this addendum says “MarshalCloud”, it means DevInSec acting through that product. It applies when MarshalCloud processes personal data on the Customer’s behalf. Where this addendum and the terms conflict on data protection, this addendum wins, except that section 8 of the terms (limitation of liability) applies to every claim under this addendum.

1. Definitions

Data protection law means the laws that apply to the processing described here: Nepal’s Individual Privacy Act, 2075 (2018), and, where they apply to the Customer’s data, the EU General Data Protection Regulation and the UK GDPR. Controller, processor, personal data, processing, data subject, and personal data breach have the meanings given in that law. Customer personal data means personal data within the customer data that MarshalCloud processes under the terms.

2. Roles

  1. The Customer is the controller of customer personal data. MarshalCloud is the processor.
  2. MarshalCloud is an independent controller for the account data of the individuals who sign in, for its own security and billing records, and for messages sent to it through its contact form. That processing is described in the privacy policy and is outside this addendum.
  3. Where the Customer is itself a processor for another organization (for example an agency managing a client’s cloud), MarshalCloud is a subprocessor, and the Customer confirms it has authority to appoint one.
  4. The Customer is responsible for the lawfulness of the data it makes available to MarshalCloud, for having a legal basis, and for giving any notices required to the individuals concerned. This matters most for device telemetry from staff computers, for cloud records that identify individuals, and for repositories it connects.
  5. Where the Customer connects its own AI provider account or endpoint, that provider is engaged by the Customer, not by MarshalCloud, and is not a MarshalCloud subprocessor.

3. Scope of processing

  1. Subject matter and purpose. Providing the MarshalCloud service: reading cloud cost, configuration, security, and change data; monitoring availability, certificates, and domains; reporting on tracked computers; producing recommendations, summaries, and AI answers; sending alerts and pages; planning and applying infrastructure changes, opening pull requests, and deploying code the Customer approves; and carrying out catalog actions the Customer approves.
  2. Duration. For as long as the Customer’s organization exists, then as set out in section 8.
  3. Categories of data subject. The Customer’s personnel and contractors who use MarshalCloud; the Customer’s personnel whose actions or accounts appear in cloud records (change records, IAM user lists, security findings) or repository alerts; the Customer’s personnel who use computers on which the Customer installs the device reporter; people in the Customer’s on-call rotations; and recipients the Customer configures for alerts.
  4. Types of personal data. Names, business email addresses, phone numbers used for paging, roles and permissions, IP addresses, user-agent strings and approximate locations in account security records, cloud identity strings and source IP addresses in change records, IAM user names and their access key and MFA status, IP addresses and network rules within cloud resource configuration, names of people in incidents, postmortems, and questionnaires, and per-computer facts: hostname, operating system version, disk and memory figures, pending update count, firewall state, and disk encryption state.
  5. Special category data. None is requested, required, or intended. The Customer must not put special category data into the service, for example in a resource name, tag, or incident note.

4. MarshalCloud’s obligations

  1. MarshalCloud processes customer personal data only on the Customer’s documented instructions. The terms, this addendum, and the Customer’s use of the product (including each approval of an action, plan, or deploy) are those instructions. If MarshalCloud must process for a legal obligation instead, it will tell the Customer first unless the law forbids it.
  2. MarshalCloud will tell the Customer if it believes an instruction breaks data protection law.
  3. People at MarshalCloud with access to customer personal data get access only where their role needs it. The duty to keep it confidential is DevInSec’s own, under section 11 of the terms; MarshalCloud does not represent that each person has signed a separate confidentiality undertaking.
  4. MarshalCloud will not sell customer personal data, share it for advertising, or use it to train AI models.
  5. MarshalCloud will give reasonable help with the Customer’s data protection impact assessments and consultations with supervisory authorities, taking account of the information available to it.

5. Data subject requests

If an individual contacts MarshalCloud about customer personal data, MarshalCloud will pass the request to the Customer without undue delay and help the Customer respond, including by locating, correcting, exporting, or deleting the data. Each user can download their own account data and erase their own account in the product. Organization data exports in the product are partial (costs, asset inventory, compliance evidence, questionnaires, activity log); anything wider is produced by hand on request.

6. Security

MarshalCloud maintains the technical and organizational measures in Annex 2, which describes what is implemented today. MarshalCloud may change a measure, but not in a way that materially lowers overall security.

7. Personal data breach

  1. MarshalCloud will notify the Customer without undue delay, and in any case no later than 72 hours after becoming aware of a personal data breach affecting customer personal data.
  2. The notice will describe what is known: the nature of the breach, the categories and approximate number of records and individuals affected, the likely consequences, and the steps taken or proposed. Where the information is not all available at once, MarshalCloud will send it in stages.
  3. MarshalCloud will help the Customer meet its own notification duties. Notice under this section is not an admission of fault.
  4. Notices go to the Customer’s organization owners by email. The Customer must keep those addresses current.

8. Deletion and return

  1. The Customer can end MarshalCloud’s access to its cloud at any time without MarshalCloud’s involvement, by removing the roles it installed, uninstalling the cluster agent or the GitHub App, or removing a tracked computer.
  2. On termination, or on request to hello@marshalcloud.com, MarshalCloud staff delete the organization. Deletion erases the organization’s rows from the primary database, deletes its billing, usage, and uptime rows from the analytics store, clears its cached data, and deletes the files its build runs left in MarshalCloud’s file storage. Each step reports cleared or not cleared, a failed step is retried once, and the report names any step that did not clear. There is no background job that keeps retrying afterwards.
  3. Some data survives organization deletion: each individual’s login record and account security events not tied to the organization; contact form submissions; and the do-not-send email list. Earlier versions of deleted build files remain in MarshalCloud’s file storage, which keeps versions and does not yet remove them automatically. MarshalCloud deletes these on request where it can.
  4. Short-lived cache entries that cannot be matched to an organization expire on their own within minutes.
  5. Automated backups of the primary database are kept for 7 days. Until they age out, backups remain subject to this addendum and are not restored into live use. The analytics store and cache have no scheduled backups. MarshalCloud’s infrastructure code defines no database snapshot kept longer than 7 days; a snapshot taken by hand outside that code would not appear in it, and MarshalCloud does not promise that none exists.
  6. MarshalCloud may retain data where the law requires it, for the period required, and only for that purpose.

9. Subprocessors

  1. The Customer gives general authorization for MarshalCloud to appoint subprocessors. The current list is at marshalcloud.com/legal/subprocessors and forms part of this addendum.
  2. Where the customer personal data is subject to the EU GDPR or the UK GDPR, MarshalCloud will give at least 30 days’ notice, by email to the Customer’s organization owners, before a new subprocessor starts processing it. For every other Customer, a new subprocessor is added to the list above before it starts, and the list shows the date each one started.
  3. A Customer given notice under the previous point may object on reasonable data protection grounds within that notice period. The parties will discuss it in good faith. If it cannot be resolved, the Customer may terminate the affected part of the service. No refund is given on such termination.
  4. Each subprocessor processes data under its own standard customer terms, including the data processing terms it offers its customers. MarshalCloud does not represent that those terms match this addendum clause by clause. MarshalCloud’s responsibility to the Customer for a subprocessor is limited as section 12 sets out.
  5. Some subprocessors are engaged only when the Customer uses the relevant feature, as the subprocessor list says.

10. International transfers

MarshalCloud is established in Nepal and hosts customer data in India (AWS Asia Pacific, Mumbai). Some subprocessors process data in other countries, including the United States.

  • The Customer decides whether the law that applies to it allows personal data to be sent to those countries, and it instructs MarshalCloud to do so by connecting the data.
  • This addendum is the only transfer document MarshalCloud offers. It includes no standard contractual clauses and no transfer impact assessment. A Customer whose law requires either should not put the data that law covers into the service until one is agreed in writing.
  • MarshalCloud does not restrict the countries from which its own staff access customer data.

11. Audit

  1. MarshalCloud will make available the information reasonably needed to show compliance with this addendum, including its security documentation.
  2. Audit rights are limited to written questions, which MarshalCloud answers within a reasonable time, and to the documentation MarshalCloud already holds: the terms, this addendum, the subprocessor list, and its security documentation. No on-site or remote audit, no inspection of systems, and no access to another customer’s data is included. A Customer that needs more than that should not use the service.
  3. MarshalCloud holds no completed SOC 2 or ISO 27001 report today.

12. Liability

Every claim under this addendum, including a claim about a subprocessor or a personal data breach, is subject to the exclusions and the cap in section 8 of the terms of service. Where data protection law does not allow a claim to be excluded, it is limited to the extent that law allows.

Annex 1: processing details

Section 3 of this addendum sets out the subject matter, duration, nature and purpose of processing, the categories of data subject, and the types of personal data. This addendum names no supervisory authority for MarshalCloud. Where the Customer’s own law designates one for the Customer, that authority is the competent one for the Customer’s data.

Annex 2: technical and organizational measures

These describe what is implemented today, in the product’s code and in the infrastructure code that defines MarshalCloud’s own hosting. Items still to be completed are named as such rather than omitted.

Access control

  • Every request is authorized against the caller’s membership of the organization it names, and every record fetched by identifier is checked against the caller’s organization through a shared enforcement point.
  • Five roles per organization (owner, admin, infosec, sre, viewer) determine what a user can read and do. Owner and admin manage the account and its connections; infosec is the lowest role that may approve a catalog action or sign off a compliance control; production plans need admin to approve and production destroys need owner; sre reads everything, runs incidents, and may request shell access; viewer is read-only.
  • For staging, production, and high-risk build changes, and for high-risk catalog actions, the approver must be a different person from the requester.
  • Two-step sign-in with an authenticator app (TOTP) is available to every user, with single-use recovery codes. It is optional, and an organization cannot yet require it. An email address must be verified before an invitation to an organization can be accepted. Ten failed sign-ins to one account within 15 minutes lock that account against further attempts while the guessing continues.
  • MarshalCloud staff roles are separate from customer roles: superadmin (full access to every organization), platform reliability (read-only in every organization), support (a directory of organizations, users, members, and invitations), and security oversight (compliance and staff activity views only). Staff opening an organization from the staff console is written to that organization’s activity log.
  • API keys are stored only as hashes, are shown once, carry scopes, and can be revoked.
  • Not implemented: single sign-on for MarshalCloud logins.

Encryption and secrets

  • Connections to the application are served over TLS 1.2 or 1.3 (AWS load balancer policy ELBSecurityPolicy-TLS13-1-2-2021-06). The primary database requires TLS, and the cache is reached over TLS.
  • The primary database, its backups, the cache, the analytics store disk, container images, and the file storage holding build artifacts and uploads are encrypted at rest with customer-managed AWS KMS keys that rotate automatically.
  • Cloud credentials, provider tokens, connector keys, authenticator secrets, and customer-supplied AI keys are additionally encrypted by the application (Fernet) with a key stored in AWS Systems Manager Parameter Store as an encrypted parameter. Per-record envelope encryption with a key management service is not yet implemented.
  • Webhook addresses and paging phone numbers are not encrypted by the application; they rely on the database’s encryption at rest and are masked wherever they are shown or logged.
  • Secrets are never returned by the API and are scrubbed from application logs; errors from providers are stored as an error type or code, not raw text.
  • Passwords are stored as PBKDF2-HMAC-SHA256 hashes at 600,000 iterations with a per-user salt.
  • The standard AWS connection uses a cross-account role and a secret external ID, so MarshalCloud holds no long-lived AWS keys for it.

Change control on customer infrastructure

  • Catalog actions: only actions in a fixed catalog can be proposed or executed, each mapped to a matching cloud permission in the remediation role. Every action waits for a named approval from a user with the infosec role or above; the setting for fully automatic execution is refused for every action kind. Irreversible actions require a typed confirmation, and high-risk actions cannot be approved from Slack.
  • Executors check the resource’s current state before most changes and record each step, who proposed, and who approved. A safety snapshot is taken before deleting a disk, and a snapshot of the server before deleting a DigitalOcean, Linode or Hetzner server; no other irreversible action keeps a copy. Rollback is available where an action is marked reversible.
  • Build changes: every apply is planned first, approved by a person according to the environment tier, preceded by a restore point (the change does not run if the backup fails), and recorded as run events. Deploys run only after approval. Pull requests are opened on the Service’s own branches and never merged by it.
  • Shell sessions require a request, an approval outside development environments, and session logging turned on in the Customer’s own account, where the recording is kept.
  • The AI surface cannot approve or execute any change. It can propose an action, and for users with the sre role or above it can write drafts (incident records, postmortem drafts, draft environments and migrations, stack input proposals, plan-only runs, and draft pull requests) that a person reviews. This is enforced by the set of tools it is given, and every item it writes is attributed to the AI. Scheduled AI runs receive no write tools at all.

Network and application security

  • Outbound requests to customer-supplied addresses (webhooks, monitors, custom AI endpoints, module sources) are resolved and refused if they point at private, loopback, link-local, or metadata addresses, and the connection is pinned to the checked address. Monitors follow at most three redirects, each re-checked.
  • The primary database and cache sit in private subnets with no internet route and accept connections only from the application. The analytics store accepts connections only from the application.
  • Database and analytics queries use parameters; identifiers come from allowlists.
  • Per-address rate limits, a stricter limit on sign-in, a per-organization daily AI token cap and monthly AI budget, a cap of five delivery attempts per alert, and at most 60 notifications per organization per hour.
  • Identifiers such as email addresses, phone numbers, IP addresses, AWS resource names, account IDs, and access key IDs are replaced with pseudonyms before data is sent to an AI provider. This is pattern-based and does not cover names in free text.

Segregation, logging, and resilience

  • Stored records are tied to their organization, directly or through their parent record, and queries are scoped by it. Organization deletion reaches every organization-scoped table, which a test enforces.
  • Action execution logs, build run events, alert delivery records, and account security events are retained. On account erasure, the IP address, device, and location on that person’s security events are blanked while the event row stays.
  • Application logs are kept for 30 days, load balancer access logs for 90 days, and network logs of refused connections for 30 days.
  • The primary database has automated backups kept for 7 days and runs in a single availability zone. The analytics store runs on a single server with no scheduled backups. The cache has no backups and is rebuilt by the application.
  • Not defined in MarshalCloud’s infrastructure code: an audit trail of administrative activity in MarshalCloud’s own AWS account, a web application firewall, and threat detection services. A service turned on by hand in the AWS console would not appear in that code, and MarshalCloud does not represent that any is.
  • Still to be completed: formal access reviews, a documented incident response runbook, an independent penetration test, and tested restores.

Questions about these documents, privacy requests, legal notices and security reports all go to one monitored inbox: hello@marshalcloud.com.