Security Architecture Views for eSTAR Submission

6.3.1 Evolving Your Design Documentation for FDA Submission

Your security architecture views shouldn't be created twice - once for development and again for FDA. Instead, plan from the beginning to create views that will serve both purposes, then enhance them as you approach submission.

The Smart Approach: Single Source Documentation

During development (Chapter 3.5), create architecture views with:

• Professional diagrams using standard notation
• Basic explanatory text covering key components
• Clear component identification and relationships
• Consistent terminology and formatting

As you approach submission, enhance these same views by:

• Expanding explanatory text to address FDA's specific concerns
• Adding explicit security control callouts
• Including traceability references to other submission documents
• Ensuring completeness against FDA's review criteria

What Changes Between Development and Submission:

Development Focus	Submission Enhancement
"How does this work?"	"How does this protect patients?"
Internal team understanding	FDA reviewer understanding
Implementation guidance	Risk mitigation demonstration
Component relationships	Attack path analysis
Basic explanations	Comprehensive security rationale

6.3.2 Pre-Submission Review Process

About 6-8 weeks before your planned submission, conduct a "submission readiness review" of your architecture views.

Review Checklist: Is Your Documentation Submission-Ready?

Explanatory Text Adequacy:

• Can someone unfamiliar with your device understand the security approach?
• Are security controls explicitly identified and explained?
• Do you address "how" and "why" for security decisions?
• Are trust boundaries clearly explained, not just shown?
• Do you address failure scenarios and recovery?

FDA-Specific Concerns:

• How does this architecture prevent patient harm?
• Where are the security controls from your risk assessment?
• How would attacks be detected and contained?
• What happens during emergency scenarios?
• How do updates maintain security?

Common Gaps Found During Review

Insufficient Explanatory Text Example:

❌ Development-Level Text:
"The device connects to the hospital network via encrypted tunnel."

✅ Submission-Ready Text:
"The device establishes a TLS 1.2 encrypted tunnel to the hospital network 
using mutual certificate authentication. This connection implements control 
CTL-NET-001 to mitigate risks RSK-003 and RSK-007 identified in our risk 
assessment. Connection failures trigger safe mode operation as documented 
in use case UC-Emergency-001."

Missing Security Context Example:

❌ Development-Level Text:
"Authentication module validates user credentials."

✅ Submission-Ready Text:
"The authentication module implements multi-factor authentication requiring 
both password and badge verification for clinical users, addressing threat 
THR-002 (unauthorized access). Emergency override procedures maintain 
patient safety while preserving audit trails as specified in control 
CTL-AUTH-003."

6.3.3 Enhancement Guidelines for Each View Type

Rather than recreating your views, enhance them systematically for submission.

Global System View Enhancements

Add to Your Existing Diagrams:

• Explicit security control annotations
• Trust boundary explanations
• Attack surface identification
• External dependency security analysis

Enhance Explanatory Text With:

Original: "Device communicates with hospital EMR system."

Enhanced: "Device communicates with hospital EMR system via HL7 over 
secure TCP (port 8443) using TLS 1.2 with certificate pinning. This 
communication path is protected by network segmentation (VLAN 100) and 
application-layer authentication, implementing controls CTL-NET-002 and 
CTL-APP-001 to address data integrity risks identified in threat model 
section 3.2."

Multi-Patient Harm View Enhancements

Add Security-Specific Analysis:

• Isolation mechanism details
• Blast radius containment specifics
• Detection and response procedures
• Recovery time objectives

Example Enhancement:

Original: "Network segmentation prevents attack spread."

Enhanced: "Network segmentation using IEEE 802.1Q VLANs with ACL-based 
inter-VLAN routing prevents lateral movement between device networks. 
VLAN 100 (device network) and VLAN 200 (hospital network) are separated 
by stateful firewall rules permitting only authenticated HL7 traffic on 
designated ports. This architecture limits blast radius to maximum 12 
devices per network segment, with automatic isolation triggered by 
anomaly detection system when 3+ failed authentication attempts occur 
within 60 seconds."

6.3.4 eSTAR Organization and File Management

Structure your enhanced documentation for easy FDA navigation.

File Organization Strategy

Single Architecture Document Approach:

18-Security-Architecture-Views-v2.1.pdf
├── Section 1: Document Overview and Cross-References
├── Section 2: Global System View
├── Section 3: Multi-Patient Harm View  
├── Section 4: Updateability/Patchability View
├── Section 5: Security Use Case Views
└── Appendix A: Component Glossary and Notation Guide

Cross-Reference Integration:

• Include reference tables linking views to risk assessment
• Map architectural components to test coverage
• Provide threat-to-control-to-architecture traceability

6.3.5 Quality Assurance Before Submission

Conduct a final review using FDA's perspective.

The "Fresh Eyes" Test

Have someone unfamiliar with your device review the enhanced views and answer:

1. Can they understand your security approach?
2. Do they see how you address the threats you identified?
3. Are the security controls clearly implemented and explained?
4. Would they feel confident this device protects patients?

Common Enhancement Oversights

Missing Context:

• Assuming reviewer knows your device's clinical use
• Not explaining why specific security controls were chosen
• Failing to address security trade-offs made

Insufficient Detail:

• Generic statements like "data is encrypted"
• Missing failure scenario explanations
• Inadequate emergency access procedures

Poor Integration:

• Views don't match risk assessment findings
• Inconsistent component naming across documents
• Missing references to other submission sections

6.3.6 Submission Timing and Process

Plan your architecture view enhancement as part of your overall submission timeline.

Recommended Timeline

12 weeks before submission:

• Review existing architecture views for gaps
• Identify enhancement needs
• Plan integration with other submission documents

8 weeks before submission:

• Enhance explanatory text
• Add FDA-specific security context
• Complete cross-reference integration

4 weeks before submission:

• Conduct fresh eyes review
• Finalize formatting and professional presentation
• Complete final consistency checks

2 weeks before submission:

• Final quality review
• File organization and eSTAR preparation
• Submit-ready document generation

Remember: Your goal is evolution, not recreation. Build on the solid foundation you created during development, enhancing it specifically for FDA review while maintaining the accuracy and clarity your team relies on.

---

Key Takeaway: The most successful submissions use architecture views that grow with the project - starting as development guidance and maturing into comprehensive FDA documentation. This approach ensures consistency, saves time, and produces better results than creating separate documents.