As infrastructure architects, we spend considerable effort securing our own environments—VPC flow logs, envelope encryption with KMS, stringent IAM policies. Yet, we routinely hand over sensitive financial data to third-party expense management platforms based on a simple SOC 2 Type II report and a vendor's security whitepaper. This is a critical architectural oversight. The security posture of your expense tool is a direct extension of your own corporate network, especially given its integration points with your IdP, accounting system, and employee credit cards.
Before signing any contract, you must conduct a technical deep dive. Treat this as a production readiness review for an external SaaS component. Here is a structured audit framework.
**First, Map the Data Flow & Integration Surface**
Diagram the data lifecycle as you would for a microservice. Key questions to formalize in a questionnaire:
* **Data Ingress:** How are receipts and transactions ingested? Is there a public API? Are there secure, time-bound pre-signed upload URLs for mobile clients, or is data being transmitted through unsecured channels?
* **Data Processing:** Where is OCR performed? Is it a transient container that discards data after processing, or are images persisted in a long-term bucket? If the vendor uses a third-party OCR provider (e.g., Google Vision), what is the data sharing agreement?
* **Data Egress:** How does data sync to your general ledger (NetSuite, Sage Intacct, etc.)? Is the connection push or pull? Are credentials stored, and if so, how? Look for OAuth2 flows over API keys.
* **Data at Rest:** Demand specifics on encryption. "AES-256 encryption" is meaningless without context. Is it envelope encryption? Who manages the root keys? Are they using a cloud KMS (e.g., AWS KMS, GCP Cloud KMS) with customer-managed keys (CMK), or is it a managed service with platform-managed keys? This is non-negotiable for financial data.
**Second, Scrutinize the API Security Model**
Request a Postman collection or OpenAPI spec for their public API. Analyze it.
* **Authentication/Authorization:** It should support OIDC using your IdP (Okta, Azure AD). Avoid proprietary API key mechanisms. Check if scopes/permissions are fine-grained (e.g., `expense:read:own` vs. `expense:read:all`).
* **Network Security:** Inquire about egress IP allow-listing. If their API needs to push to your systems, they should provide static egress IPs. Example for an AWS-hosted service, they might use a Network Load Balancer in a dedicated VPC.
**Third, Demand Technical Artifacts, Not Just Compliance Certificates**
A SOC 2 report is a start. Require these:
* **Architecture Diagrams:** High-level but showing key components (load balancers, application tier, data stores, caching layers, queuing systems). Look for network segmentation.
* **Penetration Test Report:** A recent report from a reputable third-party firm. Review the findings, severity, and remediation evidence.
* **Incident Response Playbook:** Ask for a redacted example. How do they classify incidents? What are their SLAs for notification?
* **Subprocessor List:** Specifically identify any cloud infrastructure providers (AWS, GCP, Azure), OCR providers, and analytics tools. Your data should not land in a subprocessor's environment without your explicit mapping.
**Fourth, Validate the Shared Responsibility Model**
Clarify operational security boundaries. For example:
```
Your Responsibility:
- IdP configuration (SCIM, SSO)
- Employee device security
- Allow-listing their egress IPs in your GL system
Vendor Responsibility:
- Application code security
- Patching of OS & middleware
- Securing their cloud tenant (e.g., S3 bucket policies, IAM roles)
- Database encryption and access controls
```
**Fifth, Conduct a Technical Q&A Session**
Move beyond the sales engineer. Demand a session with their lead cloud security architect or platform engineering lead. Ask pointed questions:
* "Walk me through the lifecycle of a receipt image from upload to archival. At which points is it encrypted, and with what key?"
* "How do you handle secret rotation for integrations to our accounting system?"
* "Describe your container orchestration platform (e.g., Kubernetes). What's your pod security policy? How are secrets injected into the runtime?"
* "Do you have a service mesh (e.g., Istio, Linkerd) for internal service-to-service authentication and encryption?"
The goal is not to be adversarial, but to establish them as a competent, transparent extension of your own infrastructure. If they cannot or will not provide satisfactory, detailed answers to these architectural concerns, treat it as a critical risk to your financial data fabric. The contract's SLAs should include explicit terms for security breach notification, right-to-audit clauses, and data handling specifications. Do not proceed without this due diligence.
Boring is beautiful
Mapping data flow is a decent start, but you're skipping the most critical piece: the vendor's own internal access controls. A diagram doesn't mean anything if their support engineers can run `SELECT * FROM expense_items` in production.
Ask for their access review process and ticket-based justification logs. I've seen SOC2 reports where the "least privilege" control is satisfied by having a policy document, not actual enforcement. The integration surface is only as strong as the weakest internal admin account.
- Nina
You're right, the policy document versus actual enforcement gap is where most vendors fail. SOC 2 often audits the existence of a process, not its operational rigor.
Ask for their last six months of emergency access logs. The real test is how many "break glass" events were triggered, and whether each one had a post-incident review that actually revoked the temporary credentials. A clean log with zero events might mean their normal access controls are sufficient, or it might mean their "emergency" process is the de facto normal access path.
> ticket-based justification logs
This is the key artifact. If the justification is just a ticket number from their own internal system, ask to see an example of that ticket's approval chain and resolution. Was the access truly scoped to the incident?
Sleep is for the weak