Every action is yours to audit

Standby never holds long-lived credentials to your account. You deploy a CloudFormation stack that creates a role in your account; Standby assumes it for one operation, and the session expires. Every assumption carries an ExternalId unique to you, which Standby chooses and checks, a session name set to our request ID, and session tags naming the tenant and the person who asked.

From stack 1.4.5 the role trusts only Standby's executor, the one component that acts in your account, rather than anything in Standby's AWS account, and refuses session tags naming any workspace but yours.

So every action appears in your own CloudTrail, attributed to a named supervisor — not to a generic integration. You can audit what Standby did, and who asked for it, without relying on our logs at all.

One Connect instance, not your account

Every permission below is granted on exactly two resources: the Connect instance you named, and what's inside it. If you run more than one instance, Standby can reach exactly one. The others are denied by IAM, in your account.

From stack 1.4.7 the role holds only what Standby actually calls: the reads of routing profiles, hours-of-operation details and metrics, and the writes to the override table, which it never used, are gone. Queue figures are read by the stack's own forwarder, below, under a role Standby can't assume. From stack 1.4.6 the list includes paging, connect:StartOutboundVoiceContact. AWS's IAM reference lists no resource types for it, so earlier stacks granted it on *; we tested that IAM authorizes it against the instance, and now scope it like everything else.

The permissions

Read: your contact center's shape.

connect:DescribeInstance
connect:ListQueues
connect:DescribeQueue
connect:ListUsers
connect:DescribeUser
connect:SearchHoursOfOperations

Write: two reversible queue settings. The only writes to Connect, each to one queue. Every change records the previous value first and has an expiry; before restoring, Standby re-reads the queue and restores only if it still holds what Standby set.

connect:UpdateQueueMaxContacts
connect:UpdateQueueHoursOfOperation

Write: paging. Calls an on-call supervisor through a dedicated flow the stack created, plays the alert, and listens for a keypress.

connect:StartOutboundVoiceContact

What's deliberately absent

The metric reader in your account

Separately from the role above, the stack runs a small function in your account that reads your queue figures once a minute and sends them to Standby. It uses its own role, which Standby cannot assume, and reads only:

connect:ListQueues           (your instance only)
connect:GetCurrentMetricData (your instance only)
connect:GetMetricDataV2      (your instance only)
cloudwatch:GetMetricData     (Connect's own figures)

The last two, added in stack 1.4.0, read your service level and Amazon Connect's count of contact-flow errors, every five minutes. CloudWatch's GetMetricData can't be limited to one resource in IAM; the function asks only for Connect's flow-error metrics for your instance. Before stack 1.4.5, the first two weren't limited to your instance.

The stack's own credential, which it uses to send these figures and paging outcomes to Standby, is kept in AWS Secrets Manager in your account from 1.4.5, rather than in the function's settings, where AWS's read-only access policy could see it.

What leaves your account

Standby holds identity, on-call schedules, alert rules, a pointer to each alert and an audit trail. It doesn't hold contact data, recordings, transcripts or caller details. Those never leave your AWS account.

Notifications carry no customer data by default — just an event identifier — because they pass through Apple's and Google's infrastructure. The app fetches detail over an authenticated connection when a supervisor opens it.

If Standby is down

Your contact flows carry on exactly as if nothing were set. The block in your flows returns safe defaults on any error and never throws, and it adds a median of 1.45 ms (19 ms at the 95th percentile) to a contact. A regression in that number blocks a release.

Standby never joins a call, embeds the agent softphone, or touches audio.

Removing access

Delete the CloudFormation stack. The role goes with it, Standby's access ends at that moment, and scheduled work stops instead of failing against a role that no longer exists.

The policy is versioned with the stack, and we support the current version and the two before it. Changing a permission means you deploy a new version — we can't alter the role in your account, and wouldn't want to.

Reporting a security problem

If you think you've found a vulnerability in Standby, the app or this website, email support@contact-iq.com with "Security report" in the subject. Tell us what you found, how to reproduce it, and what an attacker could do with it.

Please don't include real customer records or sensitive personal data in your first message; if they're needed, we'll arrange a secure way to share them. We'll acknowledge your report within two business days, keep you updated while we fix it, and credit you if you'd like.

Test only systems and workspaces you own or are expressly authorized to test. Don't access other people's data, take data away, run denial-of-service or load tests, use social engineering, interfere with other customers, or publish an issue before we've had a reasonable time to fix it and have agreed when to disclose it. To the extent we lawfully can, we don't intend to pursue claims arising solely from good-faith research that stays within these guidelines. This doesn't authorize anything unlawful, and it doesn't bind anyone else.

This address is also in our security.txt.