Map controls once, report across any framework

“Featured Frameworks” are the frameworks we see most often as starting points for controls programs, audits, and customer security requirements. We highlight these because they are widely adopted and because they map well to a structured controls program in SmartSuite.

Not always. Many standards and regulations are copyrighted or licensed. SmartSuite provides the system to manage frameworks operationally — mapping requirements to controls, tracking evidence, running assessments, and reporting readiness — while customers typically bring in the framework content they are licensed or authorized to use.

Exception: CRI Profile content (and related crosswalk resources) can be available in SmartSuite through our relationship with CRI.

These frameworks show up repeatedly across regulated industries and enterprise security programs. They are commonly used to establish a control baseline, guide assessments, and support audits — and they are frequently referenced in customer security reviews and procurement processes.

It depends on your goals:

• CRI Profile if you want a financial-services-oriented baseline with crosswalk benefits
• NIST CSF if you want a widely adopted program structure for cyber risk
• ISO 27001 if certification and ISMS governance are priorities
• SOC 2 if customer assurance (especially for SaaS) is a driver
• NIST 800-53 if you need a detailed control catalog for high-assurance environments
• CIS Controls if you want a practical, prioritized baseline to build momentum quickly

Teams typically:

1. add/import the framework requirements (or use provided CRI content where applicable)
2. map requirements to internal controls
3. connect evidence and testing to controls
4. track issues and remediation
5. report coverage, gaps, and readiness by framework and audit period

Control mapping is the traceable link between:

• Framework requirements (what the framework expects), and
• Internal controls (what your organization actually does).

A strong mapping includes the control(s) that satisfy the requirement, a coverage status (fully/partial/gap/not applicable), and brief rationale.

When controls are mapped correctly, you test the control once for the appropriate scope and period, attach evidence once, and then roll that result up to every framework requirement the control supports. This reduces duplicate testing and inconsistent reporting across frameworks.

Yes. Most teams crosswalk by mapping their internal controls to multiple frameworks and then reporting overlap and gaps. In addition, CRI publishes crosswalk/mapping resources, which can accelerate multi-framework alignment when CRI is used as a baseline.

Yes. The Featured Frameworks list is not the limit. Many organizations add:

• additional standards and regulations
• internal policies and control baselines
• regulator overlays and interpretations
• customer/contract security requirements

SmartSuite supports bringing these in as structured requirement sets and mapping them to your controls.

Yes. A custom framework is any structured set of requirements your organization wants to manage like a framework — with ownership, traceability to controls, evidence, testing, issues, and reporting. Common examples include internal policies, customer requirements, and regulator overlays.

Frameworks evolve. Teams typically track version/effective dates, maintain a review cadence, and keep prior versions for audit traceability. SmartSuite supports this by keeping requirements and mappings structured and reportable by audit period.

Yes. Because requirements map to controls and controls link to evidence and tests, SmartSuite can generate clean “evidence pack” views filtered by framework, audit period, scope, and ownership — making audits and customer requests faster and more consistent.

Control mapping is the traceable link between framework requirements (what a standard or regulation expects) and your internal controls (what your organization actually does). It matters because it turns GRC from a checklist into an operating model: you can assign ownership, collect evidence consistently, test controls on a cadence, and report coverage and gaps with audit-ready traceability.

Mapping connects your internal controls to framework requirements so you can operate and report your program.

A crosswalk is a reference mapping between two frameworks (Framework A → Framework B), typically published by an authoritative source.

In practice, mapping is how you run the program. Crosswalks help you accelerate multi-framework alignment, but they don’t replace control testing or evidence.

Once controls are mapped correctly, you test the control once for the right scope and period, attach evidence once, and then roll that result up wherever the control is mapped across frameworks. That reduces duplicate testing, duplicate evidence collection, and inconsistent answers when different audits or assessments ask similar questions.

Most mature programs use explicit coverage levels so reporting is defensible:

• Fully covered (the mapped control satisfies the requirement)
• Partially covered (the control contributes, but additional controls/procedures are needed)
• Not covered (gap)
• Not applicable (with documented justification)
• This is also how teams prioritize remediation and avoid over-claiming during audits.

No — and that’s the point. SmartSuite is designed around a single controls library. You maintain your controls once, then map them to as many frameworks as needed. The same control can support multiple requirements across multiple frameworks, and reporting rolls up by framework without duplicating the control work.

In most programs, evidence should be linked primarily to the control (the thing you actually execute), then rolled up to mapped requirements. This makes “test once, comply many” possible and prevents the same artifact from being uploaded repeatedly for every framework requirement that references the same control.

Crosswalks help you understand overlap between frameworks and identify where one baseline (like CRI or NIST) can support alignment to other requirements. In SmartSuite, crosswalks become actionable when paired with control mapping: you can show how a control supports multiple frameworks and produce reporting views that highlight overlap and remaining gaps.

Yes. CRI is a strong baseline because CRI publishes mapping resources that can help accelerate multi-framework alignment. In SmartSuite, teams typically map their internal controls to CRI and then use crosswalk references to support alignment reporting across other frameworks and obligations.

Mapping requires governance. Teams typically assign mapping ownership, define a review cadence (quarterly or biannually), track framework versions/effective dates, and require approval for key mapping changes. SmartSuite supports these workflows by keeping mappings as structured records and maintaining change history alongside evidence and test results.

Yes. SmartSuite supports customer-provided framework content (licensed standards, internal requirements, regulator overlays, customer obligations). Once requirements are in SmartSuite, you can map them to controls the same way, track evidence and testing, and report coverage and gaps consistently.

It’s the SmartSuite solution designed specifically to operationalize mapping at scale. It provides the structure to manage a controls library, framework/requirement libraries, mappings, evidence workflows, assessments/testing, issues/remediation, and dashboards — all connected in one system of record.

Once mappings are in place, teams commonly report:

• Coverage and gaps by framework/domain
• Unmapped requirements (clear gaps)
• Evidence freshness (current, expiring, overdue)
• Test results by period with reviewer sign-off
• Exceptions/findings and remediation SLAs
• Audit-ready evidence pack views per framework and period

A custom framework is any structured set of requirements your organization wants to manage like a framework — with ownership, mapping to controls, linked evidence and testing, exceptions, remediation, and reporting. It can be internal (policies/standards) or external (customer obligations, regulator overlays) as long as it’s the “source of truth” your teams need to manage.

Because real-world programs are shaped by more than one standard. Most teams must combine:

• internal policies and control baselines
• regulatory expectations and interpretations
• customer requirements and contract obligations business-unit or product-line standards
• Custom frameworks let you capture those requirements in a structured way and operate them alongside industry standards.

Not necessarily. “Custom” usually means you’re formalizing requirements you already have — such as policy statements, contractual obligations, or regulator interpretations — into a structured set you can map, test, evidence, and report. The goal is consistency and traceability, not inventing new requirements.

Common custom frameworks include:

• internal control standards (your baseline controls)
• policy requirement sets (security, privacy, resilience, vendor management)
• regulator overlays (how you interpret and implement regulatory expectations)
• customer security requirements (addendums, questionnaires, contractual obligations)
• program-specific baselines (cloud controls, SDLC controls, vendor controls)
• BU/team standards (requirements unique to a region, product, or business unit)

Most teams use one of three approaches:

• CSV/Excel import (fastest for large sets)
• Manual creation for smaller frameworks (with bulk editing)
• API-driven import if requirements live in another system
• Once imported, requirements become structured records you can map to controls and manage over time.

A simple starter set works well:

• Requirement ID (optional but helpful)
• Requirement title/statement
• Category/domain (so you can report)
• Applicability (BU/system/region)
• Priority/tier (optional)
• Version/effective date
• Notes/rationale (optional)

Custom requirements are mapped to your internal controls the same way external frameworks are. Evidence and test results typically attach to the control, then roll up to every mapped requirement. That’s what enables consistent reporting and avoids duplicating evidence for each requirement.

Yes. Once custom requirements are mapped to the same underlying controls, testing and evidence can be reused across requirements and frameworks. This is especially useful when customer requirements overlap with internal policies or industry standards.

Yes. Many organizations maintain multiple custom frameworks — for different business units, product lines, regions, or customer segments. SmartSuite supports this by keeping requirements structured and reportable, with filters and dashboards that slice by scope, owner, and audit period.

Teams typically maintain an “active” version and keep prior versions for audit traceability. SmartSuite supports this by tracking version/effective dates, change history, and review workflows so you can update requirements and mappings in a controlled, auditable way.

Ownership varies, but common owners include GRC, Security, Compliance, and Internal Audit — often with contributors from IT and business process owners. SmartSuite supports clear ownership by assigning framework owners, requirement owners, and control owners with review and approval workflows.

That’s common. SmartSuite supports role-based access and data governance so you can restrict who can view or edit frameworks, requirements, mappings, and evidence. Many organizations manage sensitive internal requirements and customer obligations this way.

Framework reporting means you can report readiness, coverage, gaps, evidence status, and remediation progress by framework — because framework requirements are mapped to controls, and controls are connected to evidence, testing, issues, and dashboards. It turns frameworks into live reporting inputs instead of static documents.

No. Most teams maintain a single controls program and then report it in multiple ways. Because SmartSuite keeps controls, mappings, evidence, and testing connected, you can use shared dashboards with filters (framework, audit period, business unit, system) rather than recreating dashboards for every standard.

Common reporting views include:

• coverage and gaps by framework/domain
• evidence freshness (current, expiring, overdue)
• testing results by period (pass/fail, reviewer sign-off)
• open exceptions and remediation SLAs
• executive readiness scorecards by business unit or system
• audit-ready evidence packs by framework and audit period

Evidence typically attaches to the control (the thing you actually execute). When controls are mapped to framework requirements, SmartSuite can roll up evidence status to those requirements and generate evidence pack views filtered by framework, audit period, and scope — making audit preparation much faster and more consistent.

When one control supports multiple frameworks, a single test result can roll up to every mapped requirement. That means:

• fewer duplicate tests
• fewer duplicate evidence requests
• consistent results across standards and audits
• clearer impact when a control fails (you can see every requirement affected)

Framework-aligned controls can be applied to vendors and third parties. SmartSuite can track vendor assessments, evidence requests, findings, remediation tasks, and ongoing monitoring — and roll those results up into dashboards by vendor tier, criticality, and framework domain.

Yes. Many teams link incidents, corrective actions, and resilience improvements to the controls and requirements they affect. This creates a stronger story for leadership and regulators: incidents aren’t just tracked — they drive control improvements, remediation closure, and measurable readiness reporting over time.

When a requirement is partially covered or not covered, teams can treat it as a gap and track remediation as owned work: tasks, milestones, due dates, dependencies, approvals, and closure evidence. Reporting then rolls up by framework to show progress, aging, and reduction in gaps over time.

Evidence freshness tracks whether supporting artifacts are current for the period you’re reporting. Even if a control exists, stale evidence can create audit findings. SmartSuite helps teams track evidence due dates, expirations, and review status so they can maintain continuous readiness rather than scrambling before audits.

Crosswalks help show alignment across frameworks without duplicating the underlying control work. When you start from a baseline and apply crosswalk references, reporting can highlight overlap and show where the same controls and evidence support multiple frameworks — which is especially valuable for audits, exams, and customer requests.

Yes. SmartSuite reporting typically includes scope filters such as business unit, system, region, product line, vendor tier, or audit period. This is essential for enterprise programs where frameworks apply differently across environments.

SmartSuite provides the system for mapping and reporting. Many frameworks require customer-provided or separately licensed content. Where content is provided (such as CRI Profile), SmartSuite can support that baseline and then extend reporting through mappings to other frameworks your organization uses.

SmartSuite provides a mix of practical enablement resources to help teams operationalize frameworks: guided onboarding content, templates, best-practice setup guidance, and reference articles that explain mapping, evidence readiness, assessments, and reporting.

Start by establishing a basic structure: a controls library, a framework/requirements set (imported or custom), and mappings between the two. From there, add evidence workflows and an assessment cadence. If you’re not sure where to begin, start with one baseline framework and expand outward.

Yes. Many teams start with SmartSuite templates for controls programs, evidence tracking, assessments, and remediation workflows. Templates help you launch quickly and then tailor the structure to your environment.

Absolutely. If you already have a controls library or framework content, you can import it into SmartSuite and use these resources to standardize structure, improve traceability, and strengthen reporting and audit readiness.

Most teams import requirements via CSV/Excel and organize them by framework, domain/category, and version. Once requirements are in SmartSuite, you map them to controls and connect evidence and testing so reporting can roll up by framework and period.

Attach evidence to the control, track owners and due dates, and use review/approval steps to maintain quality. Evidence freshness reporting helps you spot what’s stale or overdue before audits do, so readiness stays continuous.

Use a lightweight governance approach: track framework versions/effective dates, assign mapping ownership, schedule periodic reviews, and keep a record of changes. This ensures your mappings and reporting remain defensible as requirements evolve.

Use the Mapping & Crosswalks content to understand how control mapping reduces duplicate testing and evidence collection. Crosswalk resources can accelerate multi-framework alignment, but they work best when paired with a strong internal controls library.

Yes. Many teams use SmartSuite services and partners for onboarding, framework imports, control mapping workshops, dashboard setup, and program rollouts — especially when consolidating multiple frameworks and teams into one system.

If you don’t see a resource that matches your scenario, you can explore related Solution Suites or contact SmartSuite for guidance. Many organizations also build internal “playbooks” in SmartSuite using the same framework/mapping structure.