--- title: "If Your Reviewer Can't See the System, You Don't Have an…" description: "A Security Architecture View that earns trust: clear system boundary, honest trust zones, named data flows, marked entry points; picture does the work." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Person", "@id": "https://christianespinosa.com/#person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "image": "https://christianespinosa.com/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg", "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ], "jobTitle": "Bestselling Author, Keynote Speaker, Entrepreneur", "worksFor": { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com/" } }, { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://christianespinosa.com/#website", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "publisher": { "@id": "https://christianespinosa.com/#organization" }, "inLanguage": "en-US" }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://christianespinosa.com/#organization", "name": "Christian Espinosa", "url": "https://christianespinosa.com/", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" }, "founder": { "@id": "https://christianespinosa.com/#person" }, "sameAs": [ "https://www.facebook.com/christian.espinosa.official", "https://x.com/Ironracer", "https://www.instagram.com/christian.espinosa.official/", "https://www.youtube.com/@ChristianEspinosaOfficial", "https://www.linkedin.com/in/christianespinosa/" ] }, { "@context": "https://schema.org", "@type": "Article", "headline": "If Your Reviewer Can't See the System, You Don't Have an Architecture | Christian Espinosa", "description": "A Security Architecture View that earns trust: clear system boundary, honest trust zones, named data flows, marked entry points; picture does the work.", "image": "https://christianespinosa.com/__l5e/assets-v1/a8cc6b26-a538-4840-b52a-a09d1c2c815b/if-your-reviewer-cant-see-the-system-you-dont-have-an-architecture-card.png", "datePublished": "2026-05-28T14:00:00Z", "dateModified": "2026-05-28T14:00:00Z", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://christianespinosa.com/blog/if-your-reviewer-cant-see-the-system-you-dont-have-an-architecture" }, "author": { "@type": "Person", "name": "Christian Espinosa", "url": "https://christianespinosa.com/about" }, "publisher": { "@type": "Organization", "name": "Christian Espinosa", "logo": { "@type": "ImageObject", "url": "https://christianespinosa.com/logo.svg" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is the core idea behind \"If Your Reviewer Can't See the System, You Don't Have an Architecture\"?", "acceptedAnswer": { "@type": "Answer", "text": "I don't read architecture. I look at it. The picture has to do the work" } }, { "@type": "Question", "name": "Who is this post for?", "acceptedAnswer": { "@type": "Answer", "text": "Honestly, security leaders, medical device teams, and technical operators who want the honest version, not the vendor version. If you want a listicle, this is not that. If you want the honest version of what I have actually lived and worked through, keep reading." } }, { "@type": "Question", "name": "How do I actually apply this, not just nod along?", "acceptedAnswer": { "@type": "Answer", "text": "Pick the single line in the post that made you flinch or look away, and change one thing in your week because of it. One choice this week beats a whole framework you never touch." } }, { "@type": "Question", "name": "How does this connect to From the upcoming book?", "acceptedAnswer": { "@type": "Answer", "text": "Medical Device Cybersecurity: An In-Depth Guide; a chapter-by-chapter walkthrough of premarket submissions and postmarket surveillance, written for engineers, regulatory teams, and founders who'd rather not learn this the hard way. If the post landed, that is the natural next step; the preview the book link at the bottom of the page goes straight there." } } ] } ] --- [Skip to content](#main) [](/) [About](/about)[Speaking](/speaking)[Cybersecurity](/cybersecurity)[Programs](/programs)[Books](/books)[Media](/media) Writing Search Ctrl K[Connect](/connect) [Cybersecurity](/blog/category/cybersecurity) # If Your Reviewer Can't See the System, You Don't Have an Architecture May 28, 2026 4 min read 878 words I don't read architecture. I look at it. The picture has to do the work ![](/__l5e/assets-v1/26ab90f3-bb8b-4e0d-bdf8-cb024ad013a4/architecture-views.jpg) Published May 28, 2026 Read time 4 min In this essay 1. [01 The Four Things A Defensible View Has ](#the-four-things-a-defensible-view-has) 2. [02 The Rewrite That Earns Trust ](#the-rewrite-that-earns-trust) 3. [03 Three Views, Not One ](#three-views-not-one) 4. [04 Common Failure Modes ](#common-failure-modes) Jump to 1. [01 The Four Things A Defensible View Has ](#the-four-things-a-defensible-view-has) 2. [02 The Rewrite That Earns Trust ](#the-rewrite-that-earns-trust) 3. [03 Three Views, Not One ](#three-views-not-one) 4. [04 Common Failure Modes ](#common-failure-modes) The takeaways 1. 01 Draw a clear system boundary before anything else; fuzzy edges invalidate every downstream threat. What to do next Add threat to the next leadership review as a standing item, not a one-time slide. 2. 02 Group components by actual trust level, not network topology. What to do next Ask your security lead this week for the one-page view of trust in your environment, and read it end to end. 3. 03 Name every data flow: what data, what direction, what channel. "HTTPS" isn't a channel. What to do next Run a 20-minute tabletop with your team this month using name as the scenario. 4. 04 Mark every external entry point and tie it to the threat model. What to do next Run a 20-minute tabletop with your team this month using threat as the scenario. 5. 05 If the picture doesn't answer those four questions, the architecture isn't done. What to do next Open your current picture plan today and identify the one gap you would not want an auditor to find. Editor's note Adapted from Chapter 5 of Medical Device Cybersecurity: An In-Depth Guide. Security Architecture Views are the most under-invested artifact in most submissions, and the one with the highest use on reviewer trust. The book walks through how to construct, validate, and evolve these views across the product lifecycle. Security Architecture Views are the only thing I can take in at a glance. When they're done well, I trust them before I read a single sentence. When they're done poorly, they create a credibility gap that the rest of the file can't close. Most teams over-engineer the diagrams and under-engineer the boundaries of the system. I see it all the time. ## The Four Things A Defensible View Has I need a clear system boundary. What's the device. What's not. Where the device meets the network, the cloud, the EHR, the user, the clinician, the manufacturer. If the boundary is fuzzy, every threat downstream is contestable. **Honest trust zones.** Group components by the trust level they actually require, not by where they sit on the network diagram. The device firmware, the mobile app, the cloud backend, and the manufacturer's update service are almost never in the same trust zone, even when the marketing slide makes them look unified. **Named data flows.** Every line between components should answer three questions: what data, in what direction, over what channel. "HTTPS" is not a channel. "Mutually-authenticated TLS 1.3 with device-attested client certificates" is. **Entry points called out.** Every interface that accepts input from outside its trust zone is an attack surface. Mark them. The threat model later in the submission should map back to these exact entry points. The diagram you submit isn't art. It's a contract between you and the reviewer about what the device is and how it's defended. ## The Rewrite That Earns Trust Here's the version of this we see most often: a single rounded rectangle labeled "Cloud Platform" with one arrow labeled "HTTPS" going to a box labeled "Device." That diagram has zero trust zones, one unnamed data flow, and no entry points. The rewrite that passes splits the cloud into ingestion API, analytics service, and clinician portal; three trust zones; names the channel as mTLS 1.3 with device-attested certs, and marks the ingestion API as the only externally reachable entry point. Same system. Completely different conversation with the reviewer. The reason the second version works is not that it has more boxes. It is that every box, line, and label answers a question the reviewer was already going to ask. Where does external input enter the system? Which components share a failure domain? Which channels are authenticated, and how? Which interfaces are the threat model going to have to address? The first diagram leaves all of those questions open. The second one closes them on the page. ## Three Views, Not One A common mistake is trying to make a single diagram carry every job. It cannot. The package that lands cleanest uses three layered views, each doing one thing. **A context view.** The device sits in the middle. Every external actor and external system that touches it is on the perimeter; clinicians, patients, network infrastructure, cloud services, third-party integrations, the manufacturer's own services. The point of this diagram is to make the world the device lives in unambiguous before any internal detail is shown. **A trust-zone view.** Internal components grouped by trust level, with explicit boundaries between zones. This is where the architectural decisions become visible; what is in the secure enclave, what is in the application processor, what is in the cloud control plane, what is in the cloud data plane. A reviewer should be able to point at any zone and ask "what protects this boundary?" and find the answer in the threat model. **A data-flow view.** Every flow between zones, with channel, direction, authentication, and the sensitivity of the data being moved. This is the view the threat model lives on top of. STRIDE applies cleanly here because every flow is a candidate for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Three views, ten minutes to read, and the reviewer now has a mental model of the device that survives the rest of the submission. ## Common Failure Modes **The marketing diagram.** A logo-heavy slide that shows partner integrations and value flow. It is not an architecture view, and submitting it as one tells the reviewer the team does not know the difference. **The network diagram pretending to be an architecture view.** Subnets and firewalls are not trust zones. A device and a hospital workstation can sit on the same VLAN and live in completely different trust zones. Reviewers are looking at trust, not topology. **The single-arrow cloud.** "HTTPS" arrows from device to cloud, with no decomposition of what is in the cloud, are the single most common pattern we see, and the single most common source of follow-up questions. **Diagrams that disagree with the threat model.** If the architecture view shows three trust zones and the threat model only addresses two, the package is internally inconsistent. The reviewer will find it. It is one of the cheapest deficiencies to avoid and one of the most damaging to land. The teams that get this right ship submissions where the rest of the file flows from a single source of truth. The teams that don't end up explaining the same system three different ways across the package, and the reviewer notices. > “The diagram isn't art. It's a contract between you and the reviewer about what the device is.” Frequently asked ### What is the core idea behind "If Your Reviewer Can't See the System, You Don't Have an Architecture"? ### Who is this post for? ### How do I actually apply this, not just nod along? ### How does this connect to From the upcoming book? ### From the upcoming book Medical Device Cybersecurity: An In-Depth Guide; a chapter-by-chapter walkthrough of premarket submissions and postmarket surveillance, written for engineers, regulatory teams, and founders who'd rather not learn this the hard way. [Preview the book](/books/medical-device-cybersecurity) Share this essay [X ](https://twitter.com/intent/tweet?url=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fif-your-reviewer-cant-see-the-system-you-dont-have-an-architecture&text=If%20Your%20Reviewer%20Can't%20See%20the%20System%2C%20You%20Don't%20Have%20an%20Architecture) [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fif-your-reviewer-cant-see-the-system-you-dont-have-an-architecture) [Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fif-your-reviewer-cant-see-the-system-you-dont-have-an-architecture) [Email](mailto:?subject=If%20Your%20Reviewer%20Can't%20See%20the%20System%2C%20You%20Don't%20Have%20an%20Architecture&body=https%3A%2F%2Fchristianespinosa.com%2Fblog%2Fif-your-reviewer-cant-see-the-system-you-dont-have-an-architecture)Copy link ![Christian Espinosa, headshot](/__l5e/assets-v1/de07e44b-a8e0-4bcc-bcb0-13aec15421f1/headshot-front.jpg) About the author [Christian Espinosa](/about) · Founder & CEO, Blue Goat Cyber I'm the founder and CEO of Blue Goat Cyber, a medical device cybersecurity firm where my team has supported 250+ FDA submissions with zero failing to clear on cybersecurity. I previously founded and sold Alpine Security. I host The Med Device Cyber Podcast and wrote The Smartest Person in the Room and The In-Between: Life in the Micro, with Medical Device Cybersecurity: An In-Depth Guide out in 2026. Air Force Academy grad, 24x Ironman, climber of two of the Seven Summits. Keep reading - [ ### Threat Modeling Is the Work. Everything Else Is the Receipt. The architecture view is what the threat model is built on top of. Get the picture wrong and every threat in the document is contestable. Read essay → ](/blog/threat-modeling-is-the-work-everything-else-is-the-receipt) - [ ### What a 'Good' SBOM Actually Looks Like. And What Reviewers Reject The architecture defines the system. The SBOM enumerates what's in it. They have to agree. Read essay → ](/blog/what-a-good-sbom-actually-looks-like) [← Previous essay Why Postmarket Cybersecurity Is Where MedTech Actually Fails | Christian Espinosa ](/blog/why-postmarket-cybersecurity-is-where-medtech-actually-fails)[Next essay → What a 'Good' SBOM Actually Looks Like, And What Reviewers Reject | Christian Espinosa ](/blog/what-a-good-sbom-actually-looks-like) Related, Cybersecurity ### Need medical-device or offensive security expertise? Blue Goat Cyber, Christian's firm, runs FDA-aligned premarket submissions, penetration testing, and SBOM/SOUP analysis for medtech and high-stakes industries. [Explore Blue Goat Cyber](/cybersecurity) Christian Espinosa Bestselling author, keynote speaker, and Founding CEO of [Blue Goat Cyber](https://bluegoatcyber.com/). Helping technical leaders develop the soft skills that turn brilliance into impact. [](https://www.linkedin.com/in/christianespinosa/)[](https://x.com/Ironracer)[](https://www.instagram.com/christian.espinosa.official/)[](https://www.youtube.com/@ChristianEspinosaOfficial)[](https://www.facebook.com/christian.espinosa.official) Explore - [About](/about) - [Timeline](/timeline) - [Speaking](/speaking) - [Cybersecurity](/cybersecurity) - [Programs](/programs) Read - [Books](/books) - [Guides](/guides) - [Blog](/blog) - [Media](/media) - [Podcast Interviews](/podcasts) - [Success Stories](/success-stories) Connect - [Contact Christian](/connect) - [LinkedIn ↗](https://www.linkedin.com/in/christianespinosa/) - [Blue Goat Cyber ↗](https://bluegoatcyber.com/) - [Resources](/resources) © 2026 Christian Espinosa. All rights reserved. [Privacy](/privacy-policy)[Terms](/terms-of-use)