What do banks and credit unions use now that the FFIEC CAT is gone?
An examiner, board or customer contract now expects a cybersecurity assessment that the FFIEC Cybersecurity Assessment Tool no longer provides. The FFIEC decided not to update the CAT, and according to a September 19, 2024 notice from the Louisiana Office of Financial Institutions, the tool would no longer be available on the FFIEC website from August 31, 2025. The same notice points institutions to NIST Cybersecurity Framework 2.0 and CISA's Cybersecurity Performance Goals (CPGs) as the newer government resources to use instead.
NIST CSF 2.0 is the general outcome structure, and most banks and credit unions use the CRI Profile as the sector-specific layer on top of it. The Cyber Risk Institute built its CRI Profile on the CSF and aligned it to CSF version 2, and it turns more than 3,500 regulatory expectations into 318 control objectives called diagnostic statements. The CRI Profile is available as a free download, so the cost of the document itself is low. The real effort lies in mapping your environment against its statements and keeping that mapping current. Confirm with your primary regulator which profile, version and evidence format it expects before you start.
The right mix depends on three things: institution size, systemic impact and how much of your operation runs in the cloud. The CRI Profile sets an institution's impact tier through nine questions based on systemic impact rather than asset size, so a smaller institution can still face a deeper set of expectations if its services are critical to others. For cloud-heavy institutions, NIST's CSF Profiles page lists a Financial Sector Cloud Services Community Profile from the Cyber Risk Institute. Your institution owns its controls and its risk decisions. NIST does not certify or endorse any implementation, and only an independent assessor can issue an opinion on your program.
How the CRI Profile builds on CSF 2.0 for financial institutions
With the FFIEC CAT no longer available, many banks and credit unions are mapping their program to the CRI Profile, which is built on NIST CSF 2.0. The cards below cover what the profile contains, how its impact tier is set, what its mappings reference, and which version your examiner expects.
Built on and aligned to CSF 2.0
The CRI Profile v2.2 is based on the NIST Cybersecurity Framework and aligned to CSF version 2, so its Functions and Categories map onto the Govern, Identify, Protect, Detect, Respond and Recover structure your program already uses. Treat it as a financial sector interpretation of the CSF, not a replacement for it. Check whether your examiner refers to the CSF Core, the CRI Profile, or both, because the reporting language differs.
Regulatory expectations in one profile
The CRI Profile harmonizes more than 3,500 regulatory expectations into 318 control objectives called diagnostic statements. For a bank operating under several supervisors, this reduces the number of separate questionnaires you answer, but each diagnostic statement still needs an owner, an evidence source and a current answer. Ask your Cyber Risk Institute contacts which regulatory sources a given diagnostic statement covers before you rely on it for a specific jurisdiction.
Impact tier from nine questions
The profile sets an institution's impact tier through nine questions that measure systemic impact rather than asset size. A community credit union with a critical payment role can land in a higher tier than a larger bank with limited systemic reach. Document the answers, the rationale and who approved them, because the tier determines how many diagnostic statements apply and how deep your assessment must go.
Mappings to DORA and SP 800-53
Version 2.2 includes about 40 mappings to regulatory references and industry standards, including DORA and SP 800-53 Rev. 5. These mappings help institutions with EU operations or federal contracts reuse one body of evidence across regimes. Confirm each mapping against the source text yourself, since a mapping shows where two requirements overlap and does not establish that one satisfies the other.
Free download, no license fee
The Cyber Risk Institute offers the CRI Profile as a free download from its website, so the cost of adopting it sits in staff time, assessment work and any outside help you buy. Budget for the work of answering each diagnostic statement, gathering evidence, and maintaining the profile after version changes. Outside advisers are paid for scoping and preparation, while your examiner or independent assessor reviews the results.
CRI Profile v2.0 in the Reference Tool
NIST's CSF 2.0 Reference Tool export lists CRI Profile v2.0 as an informative reference for all 106 Subcategories, with 405 distinct CRI references. Use this view to trace a Subcategory to its CRI references when you build an internal crosswalk. Because the export shows v2.0 while the Cyber Risk Institute now publishes v2.2, confirm which version your examiner expects before you write your evidence index.
Which combination fits a bank, a credit union or a cloud-heavy institution
A community bank or credit union with a small staff usually needs a working baseline first. NIST CSF 2.0 is the structure most institutions adopt because it is voluntary, scales to small programs and gives examiners a common vocabulary. CISA's Cybersecurity Performance Goals often serve as a short, prioritized list of actions that a lean team can complete and evidence. The CRI Profile is detailed for a team of this size, so it is usually used as a reference when the examiner or a vendor asks for it rather than as the daily working document.
- Start with CSF 2.0 Core: Map existing policies, asset inventories and access controls to the six Functions, then identify the gaps that matter most.
- Use the CPGs as the action list: Treat the CPGs as a short set of high-priority controls to complete before expanding the program.
- Hold the CRI Profile in reserve: Consult it when a regulator, core provider or large partner asks for a detailed mapping.
- Check the core provider's role: Confirm which controls the core processor or managed service provider runs and which the institution must evidence itself.
- Document the decision: Record why a smaller set of practices was chosen and how the board reviewed it.
Confirm with your primary regulator whether it expects a specific framework or accepts the CSF 2.0 Core as the basis for examination.
A regional bank that runs core or customer systems through third-party cloud providers faces a different problem. Much of the evidence sits with the cloud provider, so the bank must show how it governs shared responsibility, supplier risk and configuration of services it controls. The Financial Sector Cloud Services Community Profile from the Cyber Risk Institute is built for this situation, and it sits on top of CSF 2.0 so that cloud controls map back to the same Functions the bank already reports against.
- Use the cloud Community Profile as the target: Build the target profile around the Financial Sector Cloud Services Community Profile and measure current state against it.
- Separate provider and bank controls: Record which cloud controls the provider evidences and which the bank configures, monitors and tests.
- Connect supplier risk to the Govern Function: Link cloud due diligence, contract terms and exit planning to the supply chain outcomes in GV.SC.
- Keep the CRI Profile for mapping: Use it where examiners ask for regulatory traceability across the institution.
- Review the provider's assurance reports: Confirm which reports the provider can share and whether they cover the services the bank uses.
Confirm with the regulator and the cloud provider which evidence they accept for shared controls before the assessment begins.
An institution with systemic impact or operations in several jurisdictions usually needs the broadest set of references. The CRI Profile assigns an impact tier through questions about systemic impact rather than asset size, which means a mid-sized institution with critical market roles can land in a demanding tier. The CRI Profile also maps to regulatory references such as DORA, so an institution with EU operations can use one control set to show alignment across regimes, while still checking each regulator's specific expectations.
- Determine the impact tier early: Answer the CRI Profile impact questions with the business owners, not only with security staff.
- Use the CRI Profile as the control backbone: Organize the program around its diagnostic statements and map them to CSF 2.0 Subcategories.
- Map each regime separately: Check which regulatory references the institution must show, rather than assuming a single mapping satisfies every supervisor.
- Layer the CPGs for operational priorities: Use the CPGs to set near-term actions while the full profile is being implemented.
- Plan for multiple supervisors: Assign an owner for each regulator's requests and confirm how evidence is shared across jurisdictions.
Confirm with each primary and host regulator which profile, tier and mapping they expect and how they will receive the evidence.
How the financial sector cloud profile fits your cloud services
The Financial Sector Cloud Services Community Profile from the Cyber Risk Institute is the profile to check first if your institution runs core or customer-facing workloads on a cloud provider. NIST lists it on its CSF Profiles page next to the Cloud Security Community Profile from the Cloud Security Alliance. The two are not interchangeable. The Cloud Security Alliance profile is a general cloud baseline, while the financial sector profile is written for institutions that must show how cloud services fit their CSF 2.0 outcomes and their regulators' expectations. Before you choose one, confirm which profile your examiner expects you to reference and which profile your cloud provider has mapped its own controls to.
A Community Profile can serve as a target profile in a gap analysis. Set the Target Profile to the outcomes the chosen profile describes, record your Current Profile for each cloud service, and rank the gaps by impact on customers and payment flows. Treat the profile as the starting list of outcomes, not as proof that you meet them. The institution owns this work. Each Subcategory that depends on a cloud provider needs a documented split of responsibilities, usually drawn from the provider's shared responsibility documentation, and evidence that you checked the provider's controls, such as contract terms, audit reports you have obtained, configuration settings in your own tenant and logging you have reviewed.
Ask your cloud provider three concrete questions: which Community Profile or CSF mapping it supports, which of its controls it will make available to you as evidence, and how often it updates that mapping. Then check the answers against your own records. Gaps usually appear where the provider is responsible for a control but no one at the institution has reviewed the evidence. Confirm the current version of each profile on the Cyber Risk Institute's website before you cite it in board papers or examination responses, because profile versions change and the version your examiner references matters.
What a CSF-based bank assessment costs and who gets paid
This table separates the cost components of a CSF 2.0 or CRI Profile assessment by who is paid, whether the cost is one-time or recurring, and what drives it up. No prices or durations are stated because none were supplied, so use the drivers to build a written scope and quote. The main takeaway is that the bank owns its controls and evidence, while only an independent assessor, when one is required, issues a report.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal staff time for the self-assessment and evidence | Bank staff (internal cost, no outside fee) | Recurring each assessment cycle | Number of in-scope systems, quality of existing documentation, and how many business units answer questions |
| CRI Profile or CSF gap analysis | Internal team, or an outside consultant if engaged | One-time for the first baseline, then recurring | Size of the institution, chosen impact tier, and whether the Current and Target Profiles already exist |
| Implementation partner for systems and evidence preparation | Implementation partner under a fixed-scope written agreement | One-time for remediation, sometimes recurring for upkeep | Number of gaps to close, platforms requiring configuration, and whether evidence collection is automated |
| Tooling and GRC software | Software vendor or open-source project, plus hosting and staff to run it | Recurring license or hosting, one-time setup | Whether tools are self-hosted, number of users, and integration with identity, logging and ticketing systems |
| Independent assessor, if the board or examiner requires one | Independent assessor or certification body, not DeployOpen | Recurring at each requested assessment | Scope boundaries, sampling depth, and whether the examiner accepts the output of a readiness review |
| Cloud and sector profile alignment | Internal staff, cloud provider documentation, and any consultant engaged | One-time mapping, then recurring review | Number of cloud services in scope and the shared responsibility split with each provider |
| Training for role-based staff | Training provider or internal trainers | Recurring annually | Number of specialized roles and how often staff change |
How to move from the CAT to a CSF 2.0 and CRI Profile assessment
This sequence turns the retired FFIEC Cybersecurity Assessment Tool into a documented NIST CSF 2.0 assessment, built on the CRI Profile for financial institutions. Each step produces a named output that the board and examiners can review.
Confirm the regulator's expectations in writing
Ask your primary federal or state regulator, in writing, which framework and assessment format it expects you to use after the CAT. The Louisiana Office of Financial Institutions notice of September 19, 2024 records that the FFIEC pointed institutions to NIST CSF 2.0 and CISA's CPGs, but your examiner decides what evidence is acceptable for your institution. Done means a written reply or a documented examiner expectation on file, with the owner and date recorded.
Set the target profile and impact tier
Document the Target Profile, the outcomes the board wants the institution to reach for each Subcategory, and the impact tier. The CRI Profile sets impact tier through nine questions about systemic impact rather than asset size, so the risk, finance and business leads should answer them together. Done means a signed Target Profile and a recorded impact tier, approved by the board or a board committee.
Run a current profile self-assessment by subcategory
Assess the current state of each CSF 2.0 Subcategory, using the CRI Profile's diagnostic statements where your institution is in scope. The CRI Profile v2.2 harmonizes its regulatory expectations into 318 diagnostic statements, and the CSF 2.0 Reference Tool lists CRI references for all 106 Subcategories. Done means a Current Profile with a documented rationale for each Subcategory rating, reviewed by the control owners.
Close gaps by function
Compare the Current and Target Profiles and group the gaps under the six Functions: Govern, Identify, Protect, Detect, Respond and Recover. Assign each gap an owner, a remediation action and a funding decision, and flag gaps that depend on third parties. Done means a gap register that the executive committee has accepted, with each item linked to a plan or a documented risk acceptance.
Collect evidence for each subcategory
For every Subcategory in scope, gather the artifacts that show the control operates: policies, configuration exports, access reviews, test results, tickets and training records. Store each item against its Subcategory ID so an examiner can trace a claim to proof. Done means an evidence index that maps every claimed rating to at least one dated artifact, with a named owner for refreshing it.
Have an independent party test where required
Where your regulator, board policy or the CRI Profile approach calls for independent testing, engage a qualified third party to test the high-impact Subcategories. The institution owns its controls and the assessment, and the independent party tests and reports on them, without making the institution's compliance decisions. Done means a written test report with findings, and a remediation plan for each finding that the institution has accepted or closed.
Report the results to the board
Present the Current Profile, Target Profile, gap register, evidence status and independent test findings to the board in a format it can act on. Show how each Function's gaps are being closed and which risks remain accepted, and record the board's decisions in minutes. Done means approved minutes and a dated board report that becomes the baseline for the next assessment cycle.
What a bank must have in place before an assessment starts
Before anyone scores a bank or credit union against NIST CSF 2.0, six pieces of groundwork need to exist: named accountability, a known asset and data picture, a documented risk method, a list of third parties, evidence owners, and an agreed target. Each card below says what the item is, why it matters once the FFIEC CAT is no longer available, and how to check it.
Named executive and board reporting line
Govern outcomes under GV.RR and GV.OV expect leadership accountability for cybersecurity, a named executive who owns the program, and a regular reporting path to the board. Check that the accountable executive is written into a role description, that the board receives reports on strategy outcomes and risk management performance, and that minutes show those reports were discussed. A reporting line that exists only on an org chart will not satisfy an examiner's questions.
Current asset and data flow inventories
ID.AM asks for current inventories of hardware, software, services and data, along with maps of network and data flows. Assessors cannot test a control on a system nobody has listed. Check that the inventory covers core banking, payment and digital channel systems, that owners are recorded for each entry, and that the data flow maps match what the network team sees in practice rather than an earlier architecture.
Documented risk management method
GV.RM expects a risk management strategy with defined objectives, risk appetite and tolerance, and a standard method for assessing cybersecurity risk that ties to enterprise risk management. Check that the method is written, that the institution has set tolerance levels that leadership approved, and that the same method is used across business lines. Ask whether the method produces risk ratings that are reproducible by a second assessor.
Third parties and cloud services list
GV.SC covers cybersecurity supply chain risk management, including how suppliers are prioritized, how contracts and due diligence work, and how supplier incidents are handled. Banks rely heavily on core processors, payment networks and cloud providers, so the list must include each of them with the service delivered and the data involved. Check that each critical third party has a named internal owner and a current due diligence file, and that offboarding steps exist for each.
Evidence owners for each Subcategory
An assessment fails in practice when no one can produce the evidence for a Subcategory on request. Assign one named owner to each Subcategory in scope, along with the artifact that shows the outcome, such as a policy, a configuration export, a test report or a meeting record. Check that owners have agreed to the assignment in writing, that evidence locations are documented, and that the owner list is reviewed on a set schedule.
Written target profile agreed with leadership
A Target Profile states the outcomes the institution intends to reach, and it is the basis for any gap analysis against the Current Profile. Without leadership agreement, the gap analysis has no approved end point and the results can be disputed. Check that the Target Profile lists the in-scope Subcategories, that leadership has signed off on priorities and resourcing, and that the Target Profile records which external profiles, such as the CRI Profile, were used as reference points.
Who owns the controls, who prepares evidence and who issues opinions
The bank or credit union owns its cybersecurity program, its risk decisions and its controls. Under the CSF 2.0 model, the institution sets its Organizational Profiles, chooses its Target Tier, accepts residual risk and answers to its board and regulators. NIST is not a regulator and does not certify organizations, so the institution cannot point to the framework itself as proof of compliance. Responsibilities that stay in-house include:
- Risk decisions: approving the risk appetite, the Target Profile and any gaps it chooses to accept.
- Control operation: running access reviews, monitoring, incident response and change control every day, whether or not a partner is involved.
- Accountability: naming the executive and board committee that receive reporting under the Govern Function.
- Policy approval: adopting and reviewing the cybersecurity policy and the supporting standards.
- Regulatory dialogue: explaining the program to examiners and handling any findings.
Before engaging anyone, confirm which of these owners already exist on the staff and which will need to be created.
An implementation partner such as DeployOpen helps the institution build the systems, controls and evidence that the program depends on. It does not own the controls and does not decide the risk position. In a fixed-scope engagement, the partner's work is defined in writing before it starts. Typical preparation work includes:
- Systems: deploying or hardening self-hosted open-source tooling in the institution's own environment, such as a GRC platform, logging pipeline or asset inventory.
- Control configuration: mapping existing controls to CSF Subcategories and documenting how each one operates.
- Evidence preparation: setting up collection so that access logs, change records and backup restore tests can be produced on request.
- Gap analysis support: helping staff compare Current and Target Profiles and draft remediation plans.
- Handover: documenting the environment so the institution can operate it without the partner.
A partner cannot issue an attestation, report or certificate. Ask for the written scope, the named deliverables and a clear statement that the partner's output is evidence for the institution's own review.
Only an independent assessor, auditor or certification body issues a report or opinion on the institution's program. Assessments of CSF alignment are commonly performed by audit firms or qualified assessors selected by the institution, but NIST states that it does not offer certifications or endorsements of CSF implementations and has no plans for a conformity assessment program. The Cyber Risk Institute provides the CRI Profile, a free download that many institutions use as a structured baseline, but it does not certify institutions against it. Points to confirm with any assessor include:
- Independence: that the assessor is separate from the team that built the controls.
- Scope of opinion: whether the work is an internal review, an examination or an attestation, and what each can and cannot conclude.
- Method: which criteria, profile or tiers the assessor will test against.
- Evidence requests: which records the assessor will sample, and whether the partner's artifacts are accepted as input.
- Deliverable: the exact form of the report and who may rely on it.
Ask for these terms in writing before the assessment begins.
NIST and the Cyber Risk Institute publish guidance, not certifications. NIST publishes CSWP 29 and the CSF 2.0 Reference Tool, which provide the Core, informative references and implementation examples. The Cyber Risk Institute publishes the CRI Profile, which harmonizes regulatory expectations into diagnostic statements and sets an impact tier through systemic impact questions. Neither body reviews an institution's controls or signs off on its program. Their role in an engagement is to supply the criteria:
- NIST: defines the Functions, Categories, Subcategories, Profiles and Tiers used as the structure.
- Cyber Risk Institute: supplies the CRI Profile used as a detailed control set for financial institutions.
- Regulators: decide how examiners use the framework, which the FFIEC pointed to after the Cybersecurity Assessment Tool was retired.
- Sector and cloud profiles: provide community baselines, such as the Financial Sector Cloud Services Community Profile, that a bank may choose as a target.
- Institution: chooses which criteria apply and documents why.
Confirm with your primary regulator which framework and evidence it expects before choosing a baseline.
How to choose a consultant or assessor for a bank or credit union
Banks and credit unions often bring in outside help to map NIST CSF 2.0 and the CRI Profile onto existing controls. The cards below cover the checks that separate a useful engagement from one that leaves the institution with unverified evidence. Each one should be confirmed in writing before any work starts.
Financial sector experience
Ask who on the team has worked with banks or credit unions on examination evidence, not only general security programs. Experience with state regulators, the FFIEC examination cycle and the CRI Profile's diagnostic statements is more useful than a generic CSF background. Ask for named roles and how long each person has worked in the sector, and confirm that the people in the proposal are the people who will do the work.
Independence from testing
The party that designs or implements controls should not also be the one that judges whether they work. If the same firm configures the systems and then tests them, the resulting evidence carries little weight with an examiner. Ask whether the firm will also perform the independent assessment, and if so, how it separates those roles. Confirm that only an independent auditor or assessor issues any report.
Scope in writing
Require a written scope that names the CSF Functions and Categories in play, the Current and Target Profiles, the systems and business units covered, and the sections of the CRI Profile used. Ambiguous scope is the most common cause of cost overruns and of gaps that surface during examination. Ask what is excluded, which party owns each deliverable and what changes the scope.
Evidence handover
Agree up front on the format, location and ownership of every artifact: configuration exports, access reviews, policy approvals, test results and tracking records. The institution should hold copies of all evidence in its own systems, not only in the consultant's workspace. Ask how evidence is dated, versioned and retained after the engagement ends.
Verifiable references
Ask for references from comparable institutions and contact them directly. Ask whether the work was performed in the institution's own environment, what the reference would repeat and what they would change. Confirm that any named client may be contacted under the terms the firm has agreed with them. Treat unwillingness to provide references as information in itself.
Questions before signing
Before signing, ask how the firm maps its work to examiner expectations, which tools and data sources it will use, who will hold administrative access to your systems and how that access ends. Ask what the fixed fee covers, which items are billed separately and what happens if findings require remediation. Confirm the answers in the statement of work so they can be checked later.
Questions banks and credit unions ask about the post-CAT transition
Is NIST CSF 2.0 mandatory for banks and credit unions?
No federal rule makes NIST CSF 2.0 mandatory for banks or credit unions, and NIST describes the framework as voluntary for most organizations. The obligation comes from your examiner and your contracts. The Louisiana Office of Financial Institutions notice says the FFIEC stopped updating the Cybersecurity Assessment Tool and pointed institutions to newer government resources, naming NIST CSF 2.0 and CISA's Cybersecurity Performance Goals. Ask your primary regulator in writing which framework it expects you to use for cybersecurity self-assessment, because supervisory expectations differ by institution and charter. Some customers and suppliers also require CSF alignment in their due diligence questionnaires, so review your contracts as well.
Can we use the CRI Profile without adopting the CSF?
The CRI Profile is built on the NIST Cybersecurity Framework and aligned to CSF version 2, so using it without any CSF structure would leave you with a mapping you cannot easily explain to examiners. The Cyber Risk Institute describes version 2.2 as harmonizing more than 3,500 regulatory expectations into 318 diagnostic statements, and it sets impact tiers through nine questions based on systemic impact rather than asset size. In practice, the CSF Functions and Categories give you the structure that the profile's statements sit inside. The profile is available as a free download, so the cost is in the people who answer it, not the document itself. Confirm with your regulator which profile version it accepts.
How long does the transition from the CAT take?
No fixed duration is set by the regulator notice, so the timeline depends on the starting point of your program. The main drivers are how current your asset inventory and risk assessment are, how many regulatory expectations you must map to your own controls, whether your board and risk committee need new reporting, and how many systems run in cloud or third-party environments. An institution with documented controls and a recent CAT assessment can usually map results faster than one that must first build an inventory. Ask any provider for a written scope with phases, deliverables and dependencies before agreeing to a date. DeployOpen plans and delivers fixed-scope engagements, and the timeline follows from that written scope.
Do we need an outside assessor for the CSF or the CRI Profile?
Your institution owns its assessment, but independent assessment is a separate question. NIST states that it does not offer certifications or endorsements of CSF implementations or services and has no conformity assessment program, so no body issues a NIST CSF certificate. An outside firm can prepare your evidence, run a gap analysis and help you score tiers, but only an independent auditor or assessor issues an opinion on your program. Whether your examiner or board expects an independent review should be confirmed in writing before you buy one. Be wary of any provider that offers a NIST CSF certification, because the framework does not provide one.
What does the transition need from our own team?
Your team must own the decisions, while outside help can carry much of the preparation work. Expect demand from risk management, information security, technology operations, compliance and internal audit. Internal staff must confirm which controls operate, approve risk acceptances, and sign off on the Target Profile and board reporting. Engineers usually supply the inventory, configuration and log data that prove each outcome. The effort recurs each year, because the profile must reflect changes in systems, vendors and regulations. Ask any provider which named people from your side the work requires and how much of their time it will take.
Which CSF and CRI evidence will examiners ask for first?
Examiners typically start with governance, asset inventory and risk assessment because they drive everything else. Expect requests for an approved cybersecurity risk management policy, a current inventory of hardware, software, services and data, a documented risk assessment with its results, and records showing that the board or a committee reviewed cybersecurity performance. Your gap analysis between Current and Target Profiles should link each claim to a control and an artifact, such as an access review, backup restore test or incident tabletop record. Confirm the exact evidence format with your regulator, since the notice does not specify one. Self-hosted tooling can generate much of this evidence inside your own environment, which keeps records under your control.
Does the sector cloud profile apply to our core banking platform?
It can apply if you run financial services workloads in a public cloud, but whether it fits your architecture depends on your actual service model and provider. NIST's profiles page lists a Financial Sector Cloud Services Community Profile from the Cyber Risk Institute alongside a general Cloud Security Community Profile from the Cloud Security Alliance. Use the sector profile as a reference when you write cloud requirements, then check each statement against your provider's shared responsibility terms and your own configuration. Ask your cloud provider which controls it operates and which you must operate, and record the answer in your third-party risk file.
How DeployOpen prepares systems and evidence for your assessment
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that NIST CSF 2.0 outcomes and the controls behind them can be shown to examiners and auditors. We prepare systems and evidence; the organization owns its controls, and only an independent assessor or auditor issues reports.
How we scope
- Agree in writing which CSF 2.0 Functions, Categories and Subcategories the engagement covers, including any CRI Profile statements in scope
- Confirm the systems, cloud accounts, data centers or air-gapped networks where the work will run before any build begins
- Name the examiner-facing outputs, such as current and target profiles or evidence packs, and who in your organization approves them
How we build
- Deploy and harden self-hosted open-source platforms for identity, logging, backup and monitoring so that controls generate evidence by default
- Map each in-scope control to its platform configuration, owner and collection method so that gaps are visible before the assessment
- Run security testing against the built environment and record findings, fixes and retest results as part of the evidence trail
How we hand over
- Deliver documented configurations, runbooks and an evidence map that your internal team or assessor can trace back to each control
- Provide training for the staff who will operate the platforms and collect evidence after the engagement closes
- Transfer administrative access and documentation ownership to your team in a handover session agreed in the written scope
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope delivery is complete
- Answer follow-up questions from your assessor about how a platform produced a specific piece of evidence
- Confirm with your assessor or regulator which evidence formats and retention periods they expect before the engagement starts
