We build the platforms behind this site the way we’d want any vendor handling our own data to build them. The same standards apply to engagement files, time entries, portal access, and the Salesforce work we do on your behalf.
This page is the working version of what we’d send a security team during a procurement review. If something here matters to you, it’s worth a fifteen-minute call — we’re happy to walk through the specifics.
The architectural facts that determine everything below.
These aren’t aspirations. They’re visible in the Terraform, the IAM policies, and the code review history.
Every Lambda runs under its own IAM role with the narrowest policy the workload needs — not a shared “app role.” Permissions are reviewed every time a function is added or its behavior changes. The same is true for client-side: tokens issued to portal users only carry the scopes their role actually requires.
Each request is authenticated and authorized at the API layer, regardless of where it came from. There is no “internal” network where authentication is skipped. CloudFront enforces TLS and security headers at the edge; API Gateway enforces request shape; Lambda enforces auth and tenancy; DynamoDB and S3 enforce row-level and prefix-level access in IAM.
Every piece of infrastructure — IAM policies, encryption settings, retention, network configuration — is defined in Terraform and version-controlled. Console-only changes are audited and reconciled. This makes drift visible and makes “what is our security posture today?” a question you can answer by reading a file, not by asking around.
We collect only what the work requires. Files uploaded for an engagement live in S3 with deletion protection; we don’t move them, we don’t mine them for analytics, we don’t share them. When an engagement ends, your data is returned and removed on request.
We work in your org the way we’d expect a senior consultant to work in ours.
We never copy a Salesforce password, security token, or session ID out of the org. Authentication uses OAuth 2.0 via Connected Apps with refresh tokens scoped to the minimum permissions; outbound calls use Named Credentials, not literal endpoints with embedded secrets. If you revoke our Connected App, our access is gone in seconds — nothing to clean up.
Anything we build that’s a candidate for AppExchange or a managed package follows Salesforce’s Lightning component security guidance, CRUD/FLS enforcement, sharing keyword discipline, and CSP-safe coding patterns. We use the Salesforce Checkmarx scanner against our managed-package source on every meaningful change.
Lightning Web Components never embed API keys, OAuth client secrets, or third-party tokens. Anything that needs credentials runs server-side — in Apex with Named Credentials, or in a backend Lambda authenticated via the user’s session.
Schema changes, data loads, integration testing, anything that touches a record at scale — happens in a sandbox first, every time. Production changes go through a documented change window with rollback steps written in advance.
AI assistance (currently used to parse owner-supplied consultant time entries into structured rows) is an Owner-only feature. No client data is sent to a model without an explicit Owner action.
All AI calls run on Amazon Bedrock, which keeps the request and response inside AWS’s US regions. We do not send data to OpenAI, Anthropic’s public API, or any other third-party LLM endpoint.
Amazon Bedrock’s service terms prohibit using customer prompts and responses to train foundation models. The inputs and outputs are not used to improve any model.
Every portal account — owner, consultant, client — requires TOTP-based multi-factor authentication. There is no “skip MFA” toggle and no SMS fallback. Compromised passwords alone cannot grant access.
Owner, consultant, and client portals are served from distinct hostnames and use distinct Cognito groups. A client account cannot reach owner APIs even with a valid token; group membership is checked on every request, server-side.
Access tokens issued to portals are short-lived and refreshed against Cognito. Revoking a user disables their sessions immediately at the next refresh. We do not issue long-lived service tokens to any portal client.
Every administrative action — creating a user, granting access to an engagement, deleting a file — is logged with the actor, timestamp, and target. The audit trail is queryable and retained for one year minimum.
If you believe you’ve found a security vulnerability in anything we run — this site, the portals, the APIs — tell us. Please don’t exploit it, don’t exfiltrate data, and don’t go public before we’ve had a chance to fix it.
We respond within one business day. Coordinated disclosure preferred; we will credit researchers who follow responsible-disclosure practice in any public writeup of the issue.
We use the smallest possible vendor set on purpose. The fewer vendors in the path, the fewer trust boundaries to defend.
Material changes to this list — adding or removing a sub-processor — are reflected here within seven days.
Procurement team has follow-up questions? Need a walkthrough of the architecture or a copy of our standard MNDA? Book a fifteen-minute call.
Book the call