Manage Security Requirements
Security requirements are the foundation of your product's security posture. This guide walks you through reviewing requirements, documenting how they're met, and understanding how they trace to industry standards, threats, and residual risks.
Before You Begin
- You have created a product in Product Security Hub
- You have built your architecture view with components
- You have reviewed your threat model (recommended)
🔑 Key Concept: Requirements from the Catalog
Product Security Hub matches your architecture against our curated catalog of security requirements. Each requirement is pre-mapped to industry standards including NIST CSF, NIST 800-53, ISO 27001, ISO 80001-2-2, MDS2, and Trust Service Criteria. Your job is to assess applicability and document how each requirement is being met.
Navigate to Requirements
From your product dashboard, click the Requirements tab in the top navigation bar (between Threats and SBOM).
You'll see a list of security requirements that have been matched to your product based on the components in your architecture.
Understand Grouped vs. Ungrouped View
Requirements can be displayed in two views. Toggle between them using the Grouped/Ungrouped switch in the top-right corner, or set your default preference on the Product Details page.
📋 Ungrouped View (Default)
One requirement maps to one component. You'll see duplicate requirements when they apply to multiple components.
Best for: Tracking different security controls per component
📦 Grouped View
One requirement appears once with multiple components listed. No duplicate requirements.
Best for: High-level overview of requirements coverage
💡 Why Ungrouped Matters
If your product has two microcontrollers, you need to track security controls for each separately. You might implement secure boot on one but not the other—the ungrouped view lets you document and track this difference. The one without secure boot would be flagged as a residual risk.
⚠️ Caution When Switching Views
Toggling between grouped and ungrouped views after adding content can cause issues. Content entered in grouped view will be duplicated across all component-requirement pairs when switching to ungrouped view. We recommend choosing your preferred view early and sticking with it throughout your documentation process.
Set Applicability
For each requirement, use the Applicable dropdown to indicate whether the requirement applies to your product context:
✓ Yes
The requirement applies to this component and must be addressed.
✗ No
The requirement doesn't apply to your product's specific context.
Review each requirement carefully—even if a requirement seems inapplicable, document your reasoning in the addendum field for audit purposes.
Set Requirement Status
For applicable requirements, set the Status to track implementation progress:
⏳ WIP
Work in progress—you're actively implementing controls for this requirement.
✓ Met
The requirement is fully satisfied with documented security controls.
✗ Not Met
The requirement cannot be satisfied—this automatically creates residual risk(s).
— N/A
Not applicable to this specific component context.
⚠️ Not Met Creates Residual Risks
When you mark a requirement as Not Met, Product Security Hub automatically creates residual risk entries on the Residual Risks page, tied to the associated threats. If multiple threats are associated with that requirement, multiple residual risks are created—one per threat.
Document How Requirements Are Met
The How Will This Be Met? field is where you document the specific security controls being implemented. This is critical for audits and regulatory submissions.
AI-Assisted Documentation
Click the Generate button to have AI draft documentation for how the requirement is being met. The AI pulls context from:
- • Product profile and device name
- • Product description
- • Cybersecurity details from Product Details page
- • The specific component
- • The requirement text
💡 Pro Tip: Enhance AI Output
For better AI-generated documentation, paste detailed information about your security controls into the Cybersecurity Details section on the Product Details page. The AI uses this content to write more accurate and specific documentation for how each requirement is being met.
Map to Verification & Validation
For each requirement, document how it will be tested and link to your V&V test cases:
How Will This Be Tested?
Describe the testing approach—penetration testing, code review, functional testing, etc.
V&V ID
Enter the test case ID(s) from your verification and validation documentation. This creates traceability from requirement to test.
We recommend manually mapping each requirement to specific V&V test cases for complete traceability in your regulatory submissions.
Customize Your View
Click the Settings (gear) icon to configure which columns appear in your requirements table. You can show or hide any of these fields:
Available Columns
Industry Standard Mapping Columns
Understand Industry Standard Mappings
Every requirement in Product Security Hub is pre-mapped to multiple industry standards. Enable these columns in settings to see the mappings:
️ NIST Cybersecurity Framework
NIST CSF and NIST CSF Controls columns for framework alignment.
🔐 NIST 800-53
NIST 800-53 Categories and Controls for federal security requirements.
🏥 ISO 80001-2-2
Healthcare-specific security categories for medical devices.
🌐 ISO 27001
Information security management system controls.
📋 MDS2
Manufacturer Disclosure Statement for Medical Device Security.
✅ Trust Service Criteria (COSO)
SOC 2 trust service criteria alignment.
These mappings give you instant traceability to the standards required by your customers and regulatory bodies.
Add Custom Requirements
You can add custom requirements beyond those in the catalog using two methods:
➕ Add Manually
Click + Add a New Requirement to open a popup modal and enter requirement details directly.
📥 Import via Spreadsheet
Click + Update Requirements to download our spreadsheet template, fill it out, and import. The workflow is similar to the threat import process.
Custom requirements are useful for organization-specific policies, customer contractual requirements, or emerging standards not yet in the catalog.
Review Traceability
Each requirement shows its connections in the Threat column—enabling you to see which threats are addressed by meeting this requirement.
Complete Traceability Chain
This traceability is essential for FDA submissions and demonstrates a systematic approach to security.
Best Practices
Be Specific
Document actual security controls, not generic statements. "AES-256 encryption at rest using AWS KMS" is better than "data is encrypted."
Map Every Requirement
Don't skip V&V mapping—auditors expect to see test cases linked to each security requirement.
Use Ungrouped for Differences
When components have different security controls, use ungrouped view to track each separately.
Feed the AI
Keep your Cybersecurity Details on Product Details page updated—this improves AI-generated content quality.
What's Next?
Continue with risk management and compliance:
- 1 Manage Residual Risks
Document risks from unmet requirements and unresolved vulnerabilities
- 2 Prepare for Audits
Export requirements evidence and gap analysis for audits
Ready to manage your security requirements?
Start documenting how your product meets security requirements with full traceability to industry standards.