A business unit wants to push customer PII into a new SaaS vendor next week. What does the architect require first?
Short answer
Sending PII to a third party extends your trust boundary, so first run a vendor security assessment — data handling, encryption, access controls, certifications like SOC 2 / ISO 27001, sub-processors, breach-notification terms — and put a data-processing agreement (DPA) in place before any PII flows. A pricing contract or a sales rep's verbal word is not due diligence. And a 'polished website' tells you nothing about how the vendor actually protects data; you remain accountable for it.
Handing customer PII to a new SaaS vendor is a third-party risk decision, not a procurement formality. The moment data leaves your boundary, the vendor's security posture becomes part of yours — but accountability for that data stays with you. The architect's job is to insert due diligence before the data flows, not after.
What the assessment must cover
A real vendor security assessment asks, concretely:
- Data handling and residency. Where is PII stored and processed? Who can access it?
- Encryption in transit and at rest, and how keys are managed.
- Access controls — MFA, least privilege, admin separation, logging.
- Independent assurance — current SOC 2 Type II, ISO 27001, or equivalent, reviewed (not just claimed).
- Sub-processors — who else touches the data downstream, and under what terms.
- Breach notification — how fast and through what channel they will tell you.
Then a data-processing agreement (DPA) codifies these obligations contractually — processing purpose, security measures, sub-processor controls, breach timelines, and deletion on exit — before a single record is sent. Under regulations like GDPR this is not optional.
Why the wrong answers are wrong
"Nothing — the vendor has a polished website" confuses marketing polish with security maturity; a slick UI says nothing about how data is protected behind it. "Just a signed contract on price" addresses commercials, not security or data protection — you've agreed what to pay, not how your customers' data is safeguarded. "A verbal assurance from the sales rep" is unverifiable, non-binding, and exactly what a salesperson is incentivized to give regardless of reality.
What an interviewer is probing
They want governance maturity: the instinct to treat vendors as an extension of your attack surface, knowledge of the specific evidence to demand (certifications, DPA, breach terms), and the discipline to block the data flow until due diligence is done. A strong answer ties it back to accountability — regulators and customers hold you responsible for the PII even when a third party is the one that loses it.
Likely follow-ups
- What's the difference between a SOC 2 Type I and Type II report, and which do you want?
- What must a data-processing agreement specify under regulations like GDPR?
- How do you handle the vendor's sub-processors and the risk they introduce?