> ## Knowledge Base Index > Fetch the complete knowledge base index at: https://docs.brainframe.com/sitemap.xml > Use this file to discover available pages before exploring further. > Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash). # Requirement Mapping # 🔗 Requirement Mapping > **"See how your frameworks overlap, before your auditors do."** > *Map requirements across compliance frameworks and let shared manual controls populate automatically.* Organizations rarely work with a single compliance framework. ISO 27001, GDPR, NIS2, DORA, and sector-specific standards often overlap in what they require, and controls built for one framework frequently satisfy requirements in another. Without a way to see these overlaps, teams end up duplicating work, building the same controls twice, and missing opportunities to reuse what's already in place. Brainframe's **Requirement Mapping** feature lets you map the requirements of one framework against up to five others, and automatically carries the relevant manual controls along with the mapping, so your compliance evidence stays connected across every standard you work with. --- ## 1️⃣ Accessing Requirement Mapping **Frameworks → Requirement Mapping** This opens the **Requirement Mapping** screen, where you can build a cross-framework matrix and manage mappings between requirements. ![](https://storage.crisp.chat/users/helpdesk/website/-/3/f/2/6/3f26ce462760bc00/screenshot-2026-08-14-at-10073_1r0lqpz.png =932xauto) --- ## 2️⃣ Setting Up Your Matrix ### Choosing a reference framework Select **exactly one reference framework**. This is the framework whose requirements will form the rows of your matrix, i.e. the framework you're mapping *from*. ### Choosing target frameworks Select **your target frameworks** to compare against your reference framework. These form the columns of the matrix. You can't select the reference framework again as a target.. | Tip: Start with the frameworks you're most likely to reuse controls between, such as ISO 27001 and ISO 27002, or GDPR and NIS2. --- ## 3️⃣ Reading the Matrix Once your reference and target frameworks are selected, the matrix renders automatically: * Each **row** represents a requirement from your reference framework. * Each **column** represents one of your selected target frameworks. * Each **cell** shows the target requirements currently mapped to that row's reference requirement. Empty cells mean no mapping has been created yet between that reference requirement and that target framework. --- ## 4️⃣ Creating a Mapping Click the **"+"** button inside any cell to open the mapping dialog for that reference requirement and target framework. Inside the dialog, you can: * Browse the target framework's requirements, listed in order by requirement ID * **Multi-select** any number of matching requirements * Check **"Mapping is bi-directional"** if the relationship should also apply in reverse ### One-directional vs. bi-directional mapping * **One-directional (default):** Manual controls linked to the reference requirements are pulled to the target requirements' manual controls. Nothing flows back to the reference side. * **Bi-directional:** The same propagation also happens in reverse, so manual controls already linked to the reference requirement are pushed out to the mapped target requirements as well. || Bi-directional mapping changes manual controls on *both* sides of the mapping. Review carefully before saving, especially on requirements that already have controls assigned. Click **Save** to confirm. The dialog closes and the selected requirements now appear in the corresponding matrix cell. --- ## 5️⃣ Automatic Manual Control Propagation The real value of Requirement Mapping is what happens after you save: * Manual controls linked to the mapped **target** requirements automatically appear under the **reference** requirement's manual controls, grouped by the requirement they came from. * If **bi-directional** was checked, the reference requirement's manual controls are likewise propagated out to each mapped target requirement. This means once two requirements are mapped, you don't need to manually re-assign the same control twice, it shows up where it's needed based on the mapping direction you chose. ### Editing or removing mappings If you un-map a requirement or change an existing mapping, the propagated manual controls update automatically on both sides, so nothing is left orphaned or duplicated. --- ## 6️⃣ Persistence Mappings, along with their bi-directional setting, are saved per requirement pair and persist across sessions and page reloads. Everyone with visibility on the relevant frameworks will see the same matrix and the same propagated controls. --- ## 7️⃣ Access & Permissions * Only users with existing permissions on a framework can create, edit, or delete its requirement mappings. --- ## 8️⃣ Best Practices * Map your most overlapping frameworks first (e.g. ISO 27001 ↔ ISO 27002) to get the most value from control reuse * Use bi-directional mapping deliberately, not by default, review what it will propagate before saving * Revisit mappings whenever a framework or requirement changes, so propagated controls stay accurate * Keep target framework selections focused (fewer, more relevant frameworks) to keep the matrix easy to read * Periodically audit mapped requirements to confirm propagated controls still make sense --- ## 🎯 Visual Checklist * [x] Requirement Mapping tab accessed * [ ] Reference framework selected * [ ] Target frameworks selected * [ ] Matrix reviewed for existing mappings * [ ] First requirement mapping created * [ ] Bi-directional setting reviewed for each mapping * [ ] Propagated manual controls verified under reference requirements