Security
This page — remediatedesk.com/security — reflects the security architecture of RemediateDesk as of October 1, 2026. As the product evolves, these specifications and controls are subject to continuous update. For specific technical questions, or to have any claim on this page substantiated, contact our security team at security@remediatedesk.com.
RemediateDesk runs software on your clients' endpoints and can execute commands on them. That is a significant amount of trust to ask for, so this page sets out exactly how the product is built, what it is permitted to do, where your data lives, and what we have not finished yet. It is written for the person doing a vendor review, not for a marketing audience.
The short version, so you are not hunting for it: we do not hold our own SOC 2 or ISO 27001 certification yet. What is independently audited is the AWS infrastructure underneath us. The compliance section sets out exactly what that does and does not cover.
How the agent is constrained
Most of the risk in a tool like this sits in the agent on the endpoint, so this is where the real controls are. These are properties of how it works, not configuration you have to get right.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC6.6 | The endpoint exposes no inbound surface, and deploying it requires no firewall change | The endpoint agent | Outbound-only over HTTPS on port 443. ZERO inbound firewall ports need to be opened, no port forwarding and no VPN, and it works behind NAT with no inbound rule at all. The agent never opens a listening socket, so there is nothing on the endpoint for anyone on that network to connect to — which also means compromising one machine does not hand an attacker a network path to the others. The connection is initiated by the endpoint and authenticated with its own certificate, so the direction of trust runs outward from the machine rather than inward from us. |
| CC6.3 | What may run is constrained by the approval model rather than by the account it runs as | Our backend | Every command the agent executes is sent by our backend — approved PowerShell on Windows, approved shell commands on macOS and Linux. The agent never originates work of its own and exposes no local scripting interface for anything on the machine to drive. It does run as LOCAL SYSTEM on Windows and root on macOS and Linux, because installing an update or restarting a stopped service genuinely requires it, and we would rather say that plainly than imply a lesser privilege. What constrains it is the classification of each command and the approval gate in front of it, not a smaller account: a lower-privileged account would fail at the work the product exists to do while leaving exactly the same approval question unanswered. |
| CC6.3 | A human authorises risky work, and destructive work cannot be auto-approved by any setting | Our backend | Commands are classified before dispatch. Risky and destructive ones require one-click technician approval before they execute, and a destructive command cannot be auto-approved by any setting — including a machine placed in full-trust mode, where the destructive tier is still held back. Your organization can add its own never-allowed patterns, which refuse a command outright even on approval, and its own always-ask patterns, which force a human even where our own classification would not. Approvals record who clicked and when, and an approver can approve part of a batch and reject the rest rather than being forced into all-or-nothing. |
It runs with full local privilege, and that is the point
The agent runs as a service under LOCAL SYSTEM on Windows and as root on macOS and Linux. It has to: installing updates, restarting a stuck service and reading system state are not things a limited account can do. What keeps that safe is not a smaller account. It is that the agent has no will of its own: it only ever runs commands the backend sent it, it cannot originate work, and every command is risk-classified and checked against your approval settings before it is allowed to run — set out in full under what the agent is allowed to run. Work that needs a signed-in user's own session — anything touching their desktop or profile — runs in that user's context instead of as SYSTEM, and passes the same checks.
Outbound-only on port 443
The agent opens a connection out to us. It never listens, so there is nothing to port-forward, no inbound firewall rule to add and no VPN to maintain. Device messaging runs over TCP 443 using ALPN. A second, independent HTTPS channel carries a periodic liveness signal, which is what lets us tell "the machine is off" apart from "the machine is fine but its main connection is wedged", and lets a technician restart the agent in the case where the main connection is the thing that is broken.
A certificate per machine, not a shared key
Each endpoint authenticates with mutual TLS using its own X.509 certificate, validated against an Amazon root CA pinned inside the agent rather than whatever the operating system happens to trust — so a tampered or injected certificate authority in the machine's own trust store does not get the agent to talk to it. Transport is TLS 1.2 or higher, and 1.3 where the operating system supports it.
One endpoint cannot reach another
Each certificate is authorized only for its own machine's message topics, and AWS enforces that at the broker before any of our code runs. A machine cannot subscribe to, or publish on behalf of, any other machine — including others in the same office.
Results are attributed by connection, not by what they claim
A command result's machine identity is taken from the authenticated connection it arrived on, never from the message body, and a result is only accepted for work we actually dispatched.
Every human action is attributable
Approvals, policy changes, settings changes and user management are recorded with the identity of the person who did it, taken from their authenticated session, and kept for 13 months.
Every command is logged twice
Each command and its output is recorded centrally against the machine it ran on, so there is a reviewable history of everything the product did. The agent also writes its own log locally on the endpoint — which matters when the network is the problem, because a technician can read it without the machine being able to reach us at all.
What the agent is allowed to run
This is the control that matters most, so here it is in full rather than as a summary. Every command is classified in our own code before it can run — not by asking the AI to behave, and not by the agent deciding for itself.
There are three tiers, and you choose how each machine treats them:
- Read-only checks — reading a service's state, disk space, event logs. These can run without a prompt if you allow that for the machine.
- Changes to the machine — restarting a service, clearing a cache, applying an update. A person approves these unless you have explicitly given that machine more trust.
- Destructive operations — recursive deletion, disk formatting, shadow-copy or backup deletion, disabling security software, a restart with a user signed in. These always require a person. There is no setting that turns that off, including the most permissive one.
On top of the tiers, your organization controls two lists of its own:
- Never allowed — anything matching these never runs, on any machine, at any trust level, even if a technician clicks approve. This is the only control on the page that overrides everything else.
- Always ask — commands you want a person to see every time, regardless of how the tier would otherwise classify them.
Both lists are re-checked at the moment of approval, not only when the command was first proposed — so adding a rule takes effect on work already in flight, not just future work. Approvals record who clicked, and an approver can approve part of a batch and reject the rest rather than having to take all of it or none.
Two limits worth stating because they are the questions that follow. A saved automation you have published can be set to run without a prompt, which is the point of publishing it — its commands were fixed and reviewed by one of your people at that moment, and your never-allowed list still applies to it. And the tiers protect against a command doing something destructive; they are not a judgement about whether it is the right fix. That is what the approval prompt is for.
Who can sign in, and what they can reach
Multi-factor authentication is mandatory on customer accounts, using an authenticator app. We do not offer SMS as a second factor, because it is the weakest one in common use.
Roles are enforced on the server. Accounts are root, admin or staff, and the check happens on every request rather than by hiding buttons in the interface.
Your data is separated by key, not by filter. Every lookup includes your organization's identifier as part of the storage key itself, rather than reading more broadly and filtering afterwards — which is the pattern that fails open when someone makes a mistake.
API access is authorized with signed tokens validated at the gateway. The customer application and our internal operator console use entirely separate identity pools, so a token issued for one is rejected by the other. Microsoft Entra ID single sign-on is available if you would rather not manage another password.
Your data
In transit: TLS 1.2 or higher everywhere, including the agent's connection. In practice our API, dashboard, website and device endpoint all negotiate TLS 1.3 today; 1.2 remains the floor because some older Windows versions still in service have no TLS 1.3 support at all, and refusing them would take those machines offline rather than make them safer. At rest: AWS-managed server-side encryption (AES-256) on the database and on object storage, with point-in-time recovery on the production database over a 35-day window.
The production database has point-in-time recovery enabled with a 35-day window.
No third-party telemetry. Logs, metrics and alerts stay inside AWS CloudWatch. We do not send your data to an external error-tracking or application-monitoring provider.
We delete data on a schedule that is enforced in code, not by policy alone:
| Data | Kept for |
|---|---|
| Diagnostic and chat history | About 30 days |
| Ticket records from a connected PSA | 13 months |
| Session outcome records | About 30 days |
| Dashboard trend snapshots | 90 days |
| Audit trail of human actions | 13 months |
Our Privacy Policy covers what we collect and why.
Where it is hosted
All customer data is stored and processed in the United States. We do not offer data residency in another region.
| Location | Role | What is there |
|---|---|---|
| us-east-1 (N. Virginia) | Primary region | Database, compute, API, device connectivity and identity |
| us-east-2 (Ohio), us-west-2 (Oregon) | AI inference capacity | Diagnostic text and command output for the machine being worked on |
| Global CDN edges | Static assets and installers only | Public files only — never customer data. The origin is in us-east-1 |
The last row is worth being precise about: our content delivery network has edge locations around the world, and those edges cache public assets only — the dashboard's own JavaScript, images and agent installers — and never customer data. The origin they pull from is in us-east-1.
How we organise our controls
We use the AWS Well-Architected Framework's Security Pillar as the structure for this, because it is the vocabulary most reviewers already have. AWS divides security into seven areas; each one below is a table of the controls in that area — the SOC 2 criterion it answers, the control itself, the AWS service that implements it, and how that service actually delivers it. What we have not built yet is gathered under what we are still working on.
To be precise about two claims on this page. We organise our controls this way; we have not had a Well-Architected Review performed, so the structure is our own mapping rather than an assessed result. The same goes for the SOC 2 criteria in the first column — those references are ours, chosen so a reviewer can line this up against the framework they already use. They are not an auditor’s opinion, and no SOC 2 report exists yet. The controls themselves are real and in place today; the mapping to criteria is the part that has not been independently checked.
Security foundations
How the account itself is governed, before any application control matters.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC5.2 | Control activities over technology are selected, developed and deployed, and cannot be disabled by the people they govern | AWS Control Tower | Governance is not hand-rolled. The organization runs on a Control Tower landing zone, which fixes the baseline: a separate management account, a dedicated log-archive account, a dedicated audit account, and the set of AWS Regions the organization is governed in. Its preventive controls are enforced as service control policies at the organization level, attached to the organizational unit the production account sits in rather than to the account itself — so an operator holding full administrative rights inside production still cannot remove them, because the policy is applied above where their authority ends. That set includes AWS’s own mandatory controls. Its detective controls evaluate AWS Config, so drift from the baseline is recorded as well as prevented. |
| CC6.3 | Infrastructure access is segregated so that one environment cannot administer another | AWS Organizations | Production is a member account inside the organization, not a standalone account, and the management account is a different account carrying no application workload. Billing, organizational policy and account creation live there; the data plane lives in production. The audit and log-archive accounts are separate again, which is the point: the account that generates security evidence is not the account that stores it, so an operator in production cannot reach the record of what they did. A separate development account with its own state backend and its own pipeline holds no real customer data. |
| CC7.2 | Management-plane activity is recorded to a store the recorded party cannot alter | AWS CloudTrail | Created and managed by Control Tower rather than configured by hand: one organization-level trail covering every account and every Region, delivered to the dedicated log-archive account. Log-file validation is enabled, so each delivered file is hashed and signed and a later edit or a missing file is detectable rather than silent. A production operator holds no permissions in the archive account, and the trail’s own configuration is governed by the landing zone, so it cannot be turned off, narrowed or redirected from inside production. |
| CC7.1 | Changes to infrastructure configuration are detected continuously, not at a point in time | AWS Config | Recording as part of the same Control Tower baseline. Config captures the configuration of each supported resource and every subsequent change as a timeline, which is what the landing zone’s detective controls evaluate against. The practical difference is that “the infrastructure changed” becomes a recorded event with a before and an after, attributable to a moment in time — rather than something a person has to notice by comparing two states and remembering which one was correct. |
Identity and access management
Who can sign in, what they can reach, and what our own code is permitted to do.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC6.1 | Strong authentication is enforced for every sign-in, with no exception for administrators | Amazon Cognito | Multi-factor authentication is required, not offered. The pool is set to mandatory MFA, so a user who has not yet enrolled is handed an enrolment challenge instead of a session on their next sign-in and enrols there and then — there is no grace period and no opt-out, for a user or for an administrator. Authenticator app (TOTP) only: SMS is deliberately not configured as a fallback, so no account can be taken over by porting a phone number, and we never collect a phone number at all. The enrolment QR code is rendered in your own browser from the secret, so the shared secret is never sent to a third-party image service. Customers and platform operators live in two entirely separate pools, and a token minted for one is rejected for the other because the issuer is checked, not just the signature. Federated sign-in is subject to the same MFA requirement rather than bypassing it. |
| CC6.6 | Requests from outside the system boundary are authenticated before they reach application logic | Amazon API Gateway | Every authenticated route is bound to a JWT authorizer, so the gateway validates the token — signature, expiry and issuer — before the request reaches any of our code. A request carrying a missing, expired, malformed or wrong-issuer token is rejected at the edge and our function is never invoked. That ordering is the control: a mistake in our own authorization logic cannot be the only thing standing between an anonymous caller and your data. The few genuinely public routes are enumerated explicitly rather than being whatever was left unlisted. |
| CC6.2 | Credentials are issued only through enrolment and revoked the moment access should end | AWS-managed device gateway | An endpoint is not trusted because of its name. Each one is issued its own X.509 client certificate at enrolment and authenticates with mutual TLS, so there is no password, shared secret or API key sitting on the endpoint to steal. The gateway’s authorization policy scopes that certificate to only that machine’s own message topics, bound to the device’s own identity, so a stolen certificate cannot read or act on another machine even inside the same office — and AWS enforces that before any of our code runs. The Amazon root CA is pinned inside the agent binary rather than trusted from the operating system store, so adding a certificate authority to the machine does not let anything intercept the connection. Deleting a machine revokes its certificate immediately. Two further conditions are alarmed rather than merely logged: a machine re-registering while it is still online, and one certificate being presented by two parties at once. |
| CC6.3 | Each component runs with the least privilege it needs, and drift from that is detected | AWS IAM | One execution role per function rather than a single shared role, so a function holds only the capabilities its own code uses — the unauthenticated public endpoint cannot touch identity, certificates or customer secrets, because its role grants none of that. The roles are assembled from an explicit capability list, and a test compares what is granted against the AWS calls the code actually makes, failing the build when the two drift apart. That is what stops a permission added for a one-off from quietly accumulating. No component anywhere holds a database Scan permission; reads are by key. |
| CC6.1 | Authentication can be federated to the customer’s own identity provider | Microsoft Entra ID (optional) | Optional, and off unless you turn it on. Sign-in can be federated to your own Microsoft tenant so that joiners and leavers are governed by your directory rather than by a second list of passwords we hold — when you disable someone centrally, their access here goes with it. The federated path runs through the same mandatory MFA requirement as a password sign-in: it is an alternative way to prove who you are, not a way around the control. |
Detection
AWS's name for logging and monitoring — knowing what happened, and noticing when something is wrong.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC7.2 | Management-plane activity is logged where a production operator cannot reach it | AWS CloudTrail | Every API call made against the account — by a person, by our own code, or by an AWS service acting on our behalf — with the identity that made it, the parameters and the source address. Written to the separate log-archive account, which a production operator has no access to, so the record survives the compromise of the account it describes. Log-file validation is on, so a gap or an alteration is detectable rather than invisible. |
| CC7.2 | Security-relevant events raise an alert rather than waiting to be noticed | Amazon CloudWatch | Logs, metrics and alarms across every function and queue. Alarms cover the operational signals — function errors, throttles, dead-letter queue depth, so work that failed is visible rather than silently dropped — and security-relevant ones specifically: a machine being re-registered while it is still online, and one device certificate being presented by two parties at once. Both of those are the shapes a stolen device identity would produce. Alarm state is evaluated continuously and surfaced together with per-function error counts in an internal operations view, so “is anything wrong right now” is a question with an answer rather than an inbox to search. |
| CC7.2 | Account activity is analysed continuously for indicators of compromise | Amazon GuardDuty | Enabled for continuous threat detection. It analyses account activity, DNS and network telemetry against AWS’s own behavioural models and threat intelligence — credential use from an unexpected location, reconnaissance patterns, traffic to known-bad destinations, anomalous API sequences. The reason it matters is that detection does not depend on us having anticipated that specific case and written a rule for it in advance, which is the usual failure mode of hand-built monitoring. |
| CC7.1 | Infrastructure configuration is recorded so a change is an event, not a diff | AWS Config | Continuous configuration recording across supported resources, giving each one a change timeline rather than a current-state snapshot. A change to the infrastructure therefore arrives as a recorded event with a before and an after, rather than as something a person has to spot by comparing states. The same recording is what the landing zone’s detective controls evaluate, so a drift from the governed baseline is both detected and attributable. |
| CC4.1 | Findings are aggregated and evaluated against a published standard, somewhere they cannot be quietly cleared | AWS Security Hub | Enabled in every Region we use, administered from the organization’s separate audit account, with the AWS Foundational Security Best Practices standard turned on. Findings from GuardDuty, from Config and from the standard’s own automated checks are aggregated, deduplicated and scored in one place, so the question is a posture rather than a pile of individual alerts. Because the aggregation lives in the audit account rather than in production, a production operator cannot suppress, archive or resolve a finding about their own account. |
| CC7.2 | Every human action is attributable to the person who took it | Amazon DynamoDB | Every action a person takes in the application is recorded with their identity, taken from their verified session rather than from anything the client asserts, and kept 13 months. Request bodies are never stored — only an explicit per-route whitelist of fields — which is deliberate: it means integration credentials, passwords and the contents of a command can never end up sitting in the audit log, and an install key appearing in a path is masked to its last four characters. Approvals are part of this record, so who authorised a given command on a given machine is answerable after the fact. |
Infrastructure protection
The surface an attacker can reach at all.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC7.1 | The patchable surface is eliminated rather than managed | AWS Lambda | There is no VPC of our own, no EC2 instance, no container host and no operating system to patch anywhere in the path that serves your data. AWS owns and patches the execution environment; our deployable unit is a function and its dependencies, replaced wholesale on each release rather than updated in place. There is no SSH, no bastion host and no administrative login to a server, because there is no server — which removes an entire category of control (host hardening, host patch cadence, host access review, long-lived host credentials) rather than obliging us to perform it well. A function also starts from an immutable image each time, so there is nowhere for an attacker to persist between invocations. |
| CC6.7 | Data in transit is protected, and the edge holds nothing confidential | Amazon CloudFront and S3 | TLS 1.3 in transit at the edge. The edge holds public assets only — the dashboard’s own JavaScript and images, and the agent installers — and no customer data is cached or stored there, so the globally distributed part of the system has nothing confidential in it by construction. The origin bucket is not publicly readable; it is reachable only through the distribution. The dashboard’s entry document is served no-store while hashed assets stay immutably cached, so a returning browser cannot pin itself to a previous release while still getting the cache benefit. |
| CC6.6 | Volumetric network attacks are absorbed before they reach the application | AWS Shield Standard | Always-on, applied by AWS in front of CloudFront and API Gateway with no action required from us and no configuration for us to get wrong. It absorbs the common network and transport layer floods — SYN floods, UDP reflection and amplification — at the edge of AWS’s network, before traffic reaches the application at all. Detection and mitigation are automatic and continuous rather than something triggered by us noticing an outage. |
| CC6.6 | The endpoint exposes no inbound surface to the network it sits on | The endpoint agent | Outbound-only on 443, with no inbound firewall port, no port forwarding and no VPN required to deploy it, and no listening socket ever opened. There is therefore nothing on the endpoint for anything else on that network to connect to — not us, and not an attacker who already has a foothold on the same subnet. The practical consequence is that the agent does not become a lateral-movement path between the machines it manages. |
Data protection
Encryption, retention, and keeping credentials out of places they should not be.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| C1.1 | Confidential data is encrypted at rest and remains recoverable | Amazon DynamoDB | Server-side encryption with AWS-managed keys (AES-256) on every table — on by default, applied to every item, and not something a caller can switch off for a particular write. Point-in-time recovery is enabled with a 35-day window, restorable to any second inside it, and a restore creates a new table rather than overwriting the live one, so recovery is a decision that can be inspected before it is adopted. Access is by IAM role per function rather than by a database credential that could be copied out; reads are by key and scoped to one organization’s own partition, and no component holds a Scan permission that would let it walk the table. |
| CC6.1 | Integration credentials are stored apart from application data, reachable only by the component that needs them | AWS Secrets Manager | Credentials for the integrations you connect are held in Secrets Manager — one secret per organization per provider — with the IAM policy scoped to that path prefix, so a function cannot read another tenant’s secret even by guessing its name. The application database stores only the secret’s identifier, never the secret, which means a database read, a backup or an export yields nothing usable. Secrets are fetched at the moment of use rather than being baked into environment variables, so they are not sitting in a function’s configuration where anyone with read access to it could see them. Disconnecting an integration deletes the secret outright. |
| CC6.7 | Data in transit is encrypted on every path | TLS at AWS-managed endpoints | TLS 1.2 or higher on every hop: browser to the API, endpoint agent to the device gateway over mutual TLS on port 443, and every AWS service-to-service call. 1.3 in practice at the edge. There is no internal plaintext hop anywhere, and that is a consequence of the architecture rather than a policy we maintain — we run no private network of our own for an unencrypted hop to exist on, so every call is between AWS-managed endpoints over TLS. |
| C1.2 | Data is disposed of on a defined schedule rather than by policy alone | Amazon DynamoDB TTL | Deletion is enforced per row by the database, not by a policy someone has to remember to run and not by a cleanup job that can silently stop: each record carries its own expiry and DynamoDB removes it. Diagnostic and chat history is about 30 days, session outcome records 30 days, PSA ticket records 30 days while untouched and 13 months once resolved, and the human audit trail 13 months. The periods are defined in code and the same periods are published on our privacy page, so what we tell you and what the system actually does come from one source rather than two. |
Incident response
What we can actually do when something goes wrong - contain it, recover from it, and learn from it.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC7.4 | A compromised endpoint can be cut off immediately, over a path that does not depend on what is broken | AWS-managed device gateway | A device certificate can be revoked immediately, which stops that endpoint connecting at all — not merely stops it being handed work, which would leave an attacker holding a valid identity. Separately, an agent can be force-restarted over a liveness channel that is independent of its main connection, so a machine whose primary connection is wedged is still reachable; that independence is the point, because the channel you need during an incident should not be the one that is failing. Both actions work without physical access to the machine, and a revocation is itself a recorded event. |
| A1.2 | Production data can be restored to a point in time | Amazon DynamoDB point-in-time recovery | Continuous backup with a 35-day window, restorable to any second inside it rather than to the last nightly snapshot — so the recovery point for a destructive change is the moment before it, not up to a day earlier. A restore produces a new table, leaving the live one untouched, which means the restored data can be examined and compared before anything is cut over to it. No separate backup job exists to fail silently, because the backup is a property of the table. |
| CC7.5 | Changes are identified and implemented so an incident does not recur | Written incident history, kept with the code | We keep a detailed written history of past incidents in the repository alongside the code: what happened, how it was diagnosed, the root cause, and what was changed as a result — including the cases where our first diagnosis was wrong and what corrected it. Keeping it next to the code is deliberate rather than tidy: the control and the reason it exists stay in the same place, so a later change cannot quietly undo a protection without the reason being visible to whoever is making it. A number of the controls on this page exist because of a specific entry in that history, and carry a test that fails if the protection is removed. |
Application security
How the software that runs on your endpoints is built and changed.
| SOC 2 criterion | Control | Service | How the service implements it |
|---|---|---|---|
| CC8.1 | Infrastructure changes are authorised from a reviewed plan, and the change history is traceable | Terraform, with Amazon S3 state and Amazon DynamoDB locking | All infrastructure is defined in Terraform; nothing in production is configured by clicking in a console. A change is produced as a plan, reviewed, and then applied from that saved plan file — so what reaches production is exactly what was reviewed, not a fresh plan computed afterwards that might differ. State lives in a versioned S3 bucket with locking through DynamoDB, so two applies cannot run at once and any previous state is recoverable. Applies are additionally guarded on the AWS account identifier and on the exact resource counts in the reviewed plan, and abort rather than proceed if either fails to match. |
| CC8.1 | Changes are tested and deployed through a repeatable pipeline rather than by hand | GitHub Actions | CI runs a Terraform plan on every push to the production branch, so a change that would alter infrastructure is visible as a plan before anyone applies it. Deploys are scripted rather than hand-run, including cache invalidation, which removes the class of outage where a release half-reaches users. The agent release pipeline builds, checksums and publishes in a fixed order — artifact and checksum first, version marker last — so a machine can never discover a new version before the file it names exists. |
| CC6.3 | A human authorises any action that would change a customer’s system | Our backend | Command risk classification and the approval gate live in code rather than in a model’s instructions, which is the distinction that matters: the system does not rely on the AI choosing to behave. Commands are classified before dispatch; your organization’s own never-allowed list refuses some outright even on approval; and a destructive command cannot be auto-approved by any setting, including full-trust mode. The tests covering these are verified to fail when the protection is removed, so the protection cannot be deleted silently by a later change. Approvals record who clicked, and an approver can approve part of a batch and reject the rest. |
| CC6.8 | Only verified software is installed on an endpoint | Amazon S3 and CloudFront | Agent updates are verified by SHA-256 checksum before being applied, so a truncated or substituted download is refused rather than installed. After publication the artifact is downloaded again through the CDN and re-hashed, confirming that what is actually being served matches what was built — a check that catches a failed upload or a stale edge copy, both of which have happened and been caught this way. The version marker is published only after the binary and its checksum are both in place and verified, so there is no window in which a machine can fetch a version whose artifact is missing. |
Who else touches your data
Three sub-processors — two of them AWS, plus Stripe for billing once it is switched on:
| Sub-processor | Purpose | Location |
|---|---|---|
| Amazon Web Services | All hosting, storage, compute, identity and device connectivity | United States |
| Amazon Bedrock (AWS) | AI diagnosis of endpoint problems, using Anthropic Claude models hosted by AWS | United States |
| Stripe | Subscription billing and payment processing. It receives your billing details and your endpoint count — never endpoint data, chat history or diagnostic output. Listed here because it is the next sub-processor we will add; billing is not switched on yet, so today it processes nothing | United States |
On AI specifically: diagnosis uses Anthropic's Claude models, hosted by AWS through Amazon Bedrock, and the data is processed within AWS. Your diagnostic text and command output are not sent to a separate AI vendor's own systems. What is sent is the text needed to diagnose the machine being worked on.
Separately, you may choose to connect your own systems. These are not sub-processors we impose — if you connect none of them, no data flows to any of them, and you can disconnect any of them at any time.
| Integration | What it is used for |
|---|---|
| Autotask | PSA — ticket read and update |
| ConnectWise RMM and Automate | RMM — device inventory and agent deployment |
| Microsoft 365, Entra ID, Teams | Identity, single sign-on, chat |
| Slack | Chat |
How we keep ourselves honest
Our production account is a member of an AWS Organization rather than a standalone account, and management activity is recorded by an organization-level CloudTrail with log-file validation enabled.
That trail is owned by a different account from production and delivered to a third, dedicated log-archive account. The practical consequence: a credential scoped to the production environment — the one an attacker would be trying to get, and the one we use day to day — cannot read, alter or delete the record of what it did.
The organization runs on an AWS Control Tower landing zone, which is what created and manages that trail and which applies AWS's own mandatory controls to governed organizational units as service control policies — applied above the production account, so they cannot be switched off from inside it. AWS Config records the configuration continuously, Amazon GuardDuty watches account activity for signs of compromise, and AWS Security Hub is enabled in every Region we use, administered from the organization's separate audit account so its findings land somewhere a production operator cannot quietly clear them.
Compliance
This is the part most vendor questionnaires open with, so here it is in full rather than as a badge.
RemediateDesk does not hold its own SOC 2 or ISO 27001 certification
RemediateDesk's backend services are hosted entirely within Amazon Web Services (AWS). Backend data storage, encryption at rest, physical data center operations, core network infrastructure and the underlying hypervisors inherit AWS's SOC 2 Type II, ISO 27001 and PCI-DSS Level 1 compliance standards. RemediateDesk is actively preparing for its own independent application-level SOC 2 audit.
Where that line falls, precisely, because it is the distinction that matters and the one most vendor pages blur: the infrastructure underneath us is independently audited, and our application is not. AWS's certifications cover AWS's responsibilities — the data centers, the hardware, the hypervisor, the storage and encryption primitives we build on. They say nothing about our code, our access controls, our processes or how we handle your data. Everything on this page is our own description of how the product works, not an audited finding, and we would rather you knew that before reading the rest. On PCI-DSS specifically: that is AWS's certification for the infrastructure, and we never process cardholder data ourselves, so read it as a statement about AWS rather than a claim about us.
AWS holds SOC 2 Type II and ISO 27001 certification for the infrastructure we run on, and every AWS service we use is within the scope of its current SOC 2 Type 2 report — database, compute, API, device connectivity, identity, secrets storage and AI inference. You can verify that yourself against AWS's own published lists rather than taking our word for it: AWS Security and AWS services in scope. It is worth asking any vendor for that second one — "we run on AWS" and "the specific services we run on are in audit scope" are not the same claim.
What we are still working on
Stated plainly, because you would find out during a vendor review anyway and we would rather you heard it from us.
AWS WAF in front of the API and the dashboard
Our surface is deliberately small — a managed API that validates a token before any of our code runs, a CDN serving public assets only, and a device gateway that accepts nothing but mutual TLS — and AWS Shield Standard already absorbs the common volumetric attacks. A web application firewall adds request-level rules and rate limiting on top of that, and it is the next layer we are adding. It is not in place yet, so do not count it today.
A security event management pipeline
GuardDuty, Config, CloudTrail and CloudWatch all produce findings today, and they are reviewed rather than correlated. What is missing is a SIEM collecting them into one place with alerting rules on top, and a defined on-call rota behind it.
Our own SOC 2 report
We are preparing for an independent application-level audit. No auditor is engaged yet and no observation window has started. Until that is done, the only certifications in play are AWS's, and they cover the infrastructure underneath us rather than our application.
A formally documented incident response plan
We investigate security-relevant events and alert on them, and we keep a detailed written record of past incidents. What we do not yet have is a published plan with defined severity levels and customer notification timelines.
Documentation
This page is the security overview — there is no separate architecture document, deliberately: a diagram of how the parts fit together helps a competitor more than it helps a reviewer, and what a review turns on is already here: the agent's privilege and constraints, the approval model in full, encryption and retention, the regions, the services and their controls, our sub-processors, and the gaps. The questionnaire is a direct download below — no form, no email, no waiting on us to type out 283 answers. AWS's own audit reports are not ours to hand out — AWS classifies them as confidential — but any AWS customer can pull them straight from AWS Artifact.
Vendor risk questionnaire (CAIQ v4.1)
XLSXAll 283 rows pre-filled, so you are not waiting on us. CSA's own format, so it maps onto whatever your own review process already uses. One row is still marked as needing an answer from us rather than guessed at — which standards and regulations we are contractually bound by, which we are reviewing our customer agreements to answer properly. Ask and we will tell you where that landed.
Download the questionnaireReporting a vulnerability
If you believe you have found a security problem in RemediateDesk, email security@remediatedesk.com with enough detail to reproduce it. We will confirm we have received it, and we will not pursue anyone who reports a genuine issue to us in good faith. We do not currently run a paid bug bounty.