How we handle access and data
Every vendor with AWS access is part of your attack surface — including us. This page answers the questions your security review will ask, in the same plain terms we'd want from a vendor of ours. Where a control doesn't exist, we say so.
How we access your AWS environment
- You create the role: we provide a CloudFormation or Terraform snippet for a named cross-account IAM role — you review and deploy it, so you can inspect exactly what it grants before anything is created
- External ID on the trust policy, unique to your engagement; MFA enforced on every identity that can assume it
- Read-only managed policies by default — enough for reviews, assessments, and planning; write scopes are added only when a SOW deliverable requires them, and removed after
- Role expiry is set to the engagement end date; revocation is one action on your side, at any time
- For retainers, we'll work under an identity you provision in your IAM Identity Center if you prefer — your directory, your revocation
- Never: shared credentials, long-lived access keys, or root access — we won't ask, and we'll decline if offered
Why a solo firm can be the smaller attack surface
There is exactly one person with access to your environment: the senior engineer you talked to. No rotating delivery bench, no offshore seats, no unnamed staff. One identity to scope, one to monitor, one to revoke.
If a subcontractor were ever engaged for any part of your work, that would be disclosed to you first, in writing — it's a condition in our own agreements.
Where work and data live
- Work happens inside your AWS accounts and your repositories — IaC, runbooks, diagrams, and reports are committed to your systems, not held on ours
- We avoid copying your data to our systems; anything transiently needed (a log excerpt during troubleshooting) is limited to what the task requires and deleted at engagement end
- Our own workstation: full-disk encryption, automatic OS and browser updates, screen lock, a password manager, and MFA on every business account
- Business subprocessors: Microsoft 365 (email, documents), Cloudflare (this website), GitHub (our internal repositories) — none receive your workload data as part of an engagement
- Suspected security incidents affecting your environment are reported to your named contact without undue delay — whatever we know, when we know it
The one-person question, answered directly
"What happens if you're unavailable?" is the right question to ask a solo firm, so here is the actual answer rather than a reassurance:
- Everything lands in your repos as it is produced — mid-engagement, you always hold the current state of the work, not a promise of a future handoff
- Planned absences of a week or more are flagged at least ten business days ahead; affected retainer months are prorated or paused by agreement
- If we became unavailable mid-engagement, the agreement defines a wind-down: you keep every artifact, every credential path is yours to revoke, and unearned fees come back
- Capacity is capped honestly: engagements are only sold up to what one person can genuinely reserve — the retainer page publishes this, and we hold to it
Paperwork, plainly
The contracting entity is Uptempo Cloud LLC. We'll sign a mutual NDA for scoping, and we work under a Master Services Agreement with fixed-scope SOWs — including a no-substitution clause on request: the named engineer performs the work, period.
Ask about insurance and you'll get a direct answer and a certificate the day coverage is bound — we'd rather tell you exactly where it stands than imply coverage we don't have.
Frequently asked questions
Will you complete our vendor security questionnaire?
Yes — send it. Most answers are already on this page; the rest get direct answers, including the uncomfortable ones. We do not hold a SOC 2: a solo consultancy cannot honestly claim an audited control environment, so we describe the controls we actually run instead.
Will you sign our MSA, NDA, and DPA?
We will sign a mutual NDA before scoping and can work under your MSA or ours. Data-processing terms are agreed per engagement — our default posture is to avoid holding your data at all, which makes that conversation short.
What certifications does the engineer actually hold?
Six active AWS certifications: Solutions Architect Professional, DevOps Engineer Professional, Security Specialty, Solutions Architect Associate, Developer Associate, and CloudOps Engineer Associate. Verification links are available on request, and every engagement is delivered by the person holding them.
Are you an AWS Partner?
We are independent by design. We hold six current individual AWS certifications but no partner-tier badge yet — tier programs measure headcount and logged pipeline, and we are one senior engineer. What that costs you: access to some AWS funding programs larger partners can attach. What it buys you: advice with no co-sell quota behind it, and published prices no tier-holder will show you.
Do you use subcontractors or AI tools on our environment or data?
No subcontractor touches your work without prior written disclosure — it is a condition precedent in our own subcontractor agreement. We do not feed your environment data to third-party AI services.
How is offboarding evidenced?
At engagement end you delete the IAM role (we confirm), any credentials we ever held are rotated on your side, and we certify deletion of anything transiently copied. The offboarding checklist is part of every engagement.
Put us through your vendor review
Send the questionnaire, or ask the hard question directly — you'll get a straight answer within one business day.
Start the Conversation