A SaaS request dies on row 47 of the security policy: customer data must be encrypted with keys held outside the provider. The vendor passed single sign-on, audit logs, the penetration test and data residency. The organization has no external key manager and no plan for one. The reviewer applied the control the organization agreed to, the product team had a real problem, and nobody had designed a way for those two jobs to meet. This episode takes that scene apart. The key distinction is between a security outcome and the mechanism a policy happens to name. Protecting data from unauthorized disclosure is the outcome. Keeping the keys outside the provider is one mechanism among several on the key-management ladder that AWS, Google Cloud and Microsoft all publish: provider-managed keys, customer-managed keys, bring your own key (BYOK), a customer-owned hardware security module (HSM), and an external key manager (hold your own key, HYOK). AWS's own documentation calls its options "equally secure" and puts the difference in operational trade-offs, and the UK National Cyber Security Centre advises avoiding BYOK and HYOK unless regulations require them. Then the turn. Nobody decides to block adoption. A policy names a mechanism, the platform cannot supply it, and there is no exception path, so the request stalls or the team quietly routes around the policy. The standards behind the policy are more flexible than the policy itself: NIST SP 800-53B, PCI DSS v4.0.1 and NIST CSF 2.0 already provide for compensating controls, a customized approach, and risk-response criteria by data class. We walk through five ways through -- compensating controls, restricted data classifications, time-boxed exceptions with an owner and an expiry, phased adoption, and remediation roadmaps -- and what makes each one credible rather than a loophole. We also keep the honest limit in view: some mechanisms really are the requirement, and compensating controls are not a negotiating tactic. The practical takeaway for architects and technology leaders: keep a capability register, write requirements as outcome, evidence and permitted mechanisms, and give every hard rule an exit. Controls should enable risk management, not accidentally prevent the organization from operating. This is Part 1 of the series "The Engineering of Trade-offs". Read the full article at www.golodiuk.com. Dmytro Golodiuk is a highly experienced technology professional with over 18 years in the software industry. His proficiency spans cloud computing, enterprise platforms, software development, and integration technologies, with deep expertise in the Microsoft ecosystem. Dmytro combines his technical knowledge with formal Enterprise Architecture frameworks like TOGAF and ArchiMate to deliver robust and practical solutions. In addition to his architectural work, Dmytro is a passionate mentor dedicated to helping others grow in their IT careers. https://mentor.sh/mentors/dmytro_golodiuk 🟦 IF YOU'RE A MID TO SENIOR ENGINEER WHO Aspires to become a Solution Architect. Recognizes the need to develop beyond great technical skills. Is ready to embrace the mindset and responsibilities of an architect. ✅ Then I'm the mentor you're looking for. Let's work together to unlock your potential and lay the bridge to your future as a Solution Architect. https://mentor.sh/mentors/dmytro_golodiuk --------- This podcast episode is an AI-narrated version of the original text-based articles from Dmytro's personal blog, which you can find at www.golodiuk.com/news
