By Steve Carroll, Principal, BNP, Inc. · October 22, 2026
The problem is usually the names, not the data
Most business continuity management (BCM) reports that confuse readers are not short on data. They are built on names that nobody outside the department can interpret. A business impact analysis (BIA) report that lists “Wires,” “Core,” “Acme,” and “GL Recon” side by side forces the reader to guess which item is a process, which is a system, and which is a company.
Your governance, risk, and compliance (GRC) database can only report what was typed into it. When business functions, resources, and third-party service providers (TPSPs) are named without a shared convention, every downstream report inherits the confusion: interdependency maps, recovery time objective (RTO) summaries, vendor criticality lists, and the board package.
The fix is a naming discipline that treats each record type differently:
- Business functions are work, so name them with an action verb.
- Resources are tools, so name them with a noun phrase.
- Third-party service providers are organizations, so name them with their legal entity name.
The rest of this article explains each rule, gives examples, and closes with a one-page reference you can hand to anyone who enters data.
Why naming discipline matters to examiners
The Federal Financial Institutions Examination Council (FFIEC) Business Continuity Management booklet expects three separate lists, and expects them to connect. Management should develop a BIA that “identifies all business functions and prioritizes them in order of criticality,” and should “identify, analyze, and prioritize interdependencies among business functions and systems” (Section III.A). The same section says management “should also inventory third-party service providers, including specific services they provide.”
Those are three different kinds of things: functions, the assets and systems they rely on, and the providers behind them. If the names blur together, the interdependency analysis cannot be read, and the inventories cannot be reconciled.
The booklet also says the BIA methodology “should be repeatable, allowing management to reevaluate information after significant changes.” A repeatable method depends on stable, unambiguous record names. Examiners are told to review the “identification of critical business functions” and the “communication of BIA results throughout the entity,” so the names you choose are what the examiner reads.
Third-party guidance points the same way. The 2023 Interagency Guidance on Third-Party Relationships: Risk Management lists “maintaining a complete inventory of its third-party relationships” as a core practice. A vendor list cluttered with product names is not a complete or accurate inventory of relationships.
Business functions: name the work being done
Name every business function (process) with an action verb followed by the object of the work. A reader should be able to picture someone doing the task from the name alone.
This is how the most widely used process taxonomy works. APQC’s Process Classification Framework rules state that “all items in the PCF begin with a verb describing the process,” and give the example “Develop Vision & Strategy,” not “Strategy & Vision Development.” The Federal Plain Language Guidelines make the same case for active voice: it “makes it clear who is supposed to do what” and “eliminates ambiguity about responsibilities.”
| Avoid | Use instead | Why |
|---|---|---|
| Wires | Process Outgoing Wire Transfers | Says what is done, and which direction |
| GL Recon | Reconcile General Ledger Accounts | Spells out the work and drops jargon |
| Loan Ops | Fund Approved Consumer Loans | “Ops” hides several distinct tasks |
| Deposit Operations | Open New Deposit Accounts | A department name is not a process |
| Payroll | Process Employee Payroll | Distinguishes the work from the Payroll System resource |
| ACH | Originate Automated Clearing House (ACH) Payments | Verb, full name, and acronym in parentheses |
Three practical rules keep function names clean:
- Start with a present-tense verb. Process, Reconcile, Originate, Review, Approve, Monitor, Report.
- Name one process per record. If the name needs “and” to join two unrelated tasks, it is probably two functions with different recovery needs.
- Do not name a department, team, or system. “Deposit Operations” belongs in the department field. “Core Banking System” is a resource.
Resources: name the tool, not the action or the vendor
Name every resource with a noun phrase. The resource list is an inventory of the tools a function uses: software applications, systems, hosted services, equipment, facilities, and data. It is not a list of actions, and it is not a vendor list.
The FFIEC booklet frames this list as an inventory of “critical assets (e.g., people, hardware, software, data, information, and cash)” and infrastructure (Section III.A). Assets are things, so their names should read like things.
A resource can be named in one of two ways. Pick one approach for each resource and apply it consistently.
- Generic name: describes what the tool is. Examples: Consumer Loan Origination System, Core Banking System, Wire Transfer System, Item Processing Imaging System.
- Branded product name: the product’s market name, when staff know it by that name. Use the product name only, and add a generic description in a separate field so an outsider knows what it does.
Keep vendor names out of resource names. The company that sells the product belongs in the TPSP list, linked to the resource. If a product’s brand includes the maker’s name, the full product name is acceptable, but the company name by itself is never a resource.
| Avoid | Use instead | Why |
|---|---|---|
| Acme | Core Banking System | “Acme” is a company; the resource is the system |
| Process loans in LOS | Consumer Loan Origination System | An action belongs in the function list |
| Acme Technologies, Inc. – Online Banking | Online Banking Platform | Vendor goes in the TPSP record |
| Email and Calendar Service | Says what the service is | |
| Server 3 | Imaging Application Server | A hostname means nothing to a reader |
All company and product names in this article are illustrative.
Third-party service providers: name the legal entity
Name every TPSP or vendor with its legal entity name, including the entity designator such as Inc., LLC, Corp., L.P., or N.A. A TPSP is an organization you have a relationship with, so the record should identify that organization the way a contract or a court would.
This is harder than it sounds because many companies trade under a name that is not their legal name. The U.S. Small Business Administration explains that a “doing business as” (DBA) name is “also known as a trade name, fictitious name, or assumed name.” A provider’s DBA, its brand, and its flagship product can all share the same word, while the contracting entity is a separate subsidiary.
Dig until you find the real legal name. These free sources help:
- The signed contract or master services agreement. The legal name and entity type appear in the opening paragraph and signature block. Start here.
- The Global Legal Entity Identifier Foundation (GLEIF) LEI search. Level 1 data includes “the official name of the legal entity as recorded in the official registers,” and anyone can search it “free of charge and without the need to register.”
- The U.S. Securities and Exchange Commission (SEC) EDGAR company search, for publicly traded providers and their filings.
- The Secretary of State business entity search in the provider’s state of incorporation.
- The provider’s invoices, W-9, and SOC report. These usually name the entity that actually bills you or was audited.
| Avoid | Use instead | Why |
|---|---|---|
| Acme | Acme Technologies, Inc. | Includes the entity designator |
| AcmeCore | Acme Technologies, Inc. | AcmeCore is the product; list it as a resource |
| Acme Payments | Acme Payment Services, LLC | The DBA and the contracting subsidiary differ |
| Bob at the IT company | Northwind IT Consulting, LLC | A contact person is not an organization |
When a provider has several affiliated entities, record the one that signed your contract. If you also need the brand name for searching, keep it in a separate “Also Known As” or “DBA” field rather than in the name.
Make names search-friendly and examiner-friendly
Write every name for the outsider who will read it: an examiner, an auditor, a new hire, or a board member. Insiders know what “BSA,” “RDC,” and “LOS” mean. Examiners may not know your shorthand, and a search for “Remote Deposit Capture” will never find a record named “RDC.”
Spell it out, then put the acronym in parentheses. Write “Bank Secrecy Act (BSA) Monitoring System,” not “BSA System.” The Federal Plain Language Guidelines say to “always define an abbreviation the first time you use it.” In a database, every record is someone’s first time, so define it in every name. A search for either the full term or the acronym then finds the record.
These additional practices keep a GRC database readable and reportable. They are recommended practices drawn from data management experience, not regulatory requirements.
- Use one name per thing. The plain language guidelines warn, “You will confuse your audience if you use different terms for the same concept.” Pick “Wire Transfer System” and never also enter “Wire System” or “Wires Platform.” Check for an existing record before you add a new one.
- Use title case consistently. “Reconcile General Ledger Accounts,” not “reconcile general ledger accounts” or “RECONCILE GL ACCOUNTS.” Mixed casing makes duplicates harder to spot and sorted reports harder to scan.
- Keep status out of the name. Words like “OLD,” “NEW,” “DO NOT USE,” or “(retired)” belong in a status field. When a name changes meaning over time, the reports that use it go stale.
- Keep versions, environments, and locations out unless they are truly different records. “Core Banking System” is one resource. Create a separate record only when a second instance has its own recovery requirements, such as a separate disaster recovery site.
- Put the detail in the description field. The name identifies the record; the description explains it. A short, precise name with a full description reads better in every report.
- Avoid special characters and internal codes. Slashes, ampersands, and ticket or asset numbers can break exports and searches. Store codes in their own fields.
- Assign an owner for naming. One person, often the BCM coordinator, should approve new records and merge duplicates. A convention only works if someone enforces it.
Quick reference
Hand this table to anyone who adds or edits records in the GRC database.
| Record type | What it is | Grammatical form | Pattern | Example | Never include |
|---|---|---|---|---|---|
| Business function | Work being done | Active verb phrase | Verb + object | Process Outgoing Wire Transfers | Department, system, or vendor names |
| Resource | A tool the work uses | Noun phrase | Generic name or branded product name | Consumer Loan Origination System | Vendor names, actions |
| Third-party service provider | An organization | Legal entity name | Name + entity designator | Acme Technologies, Inc. | Product names, contact names |
| All three types | Rules for every name | Full words | Full term, then (ACRONYM) | Remote Deposit Capture (RDC) Platform | Bare acronyms, status words, codes |
To clean up an existing database, work in this order:
- Export the three lists (functions, resources, TPSPs) to a spreadsheet.
- Move misfiled records. Vendor names in the resource list go to the TPSP list; actions in the resource list go to the function list.
- Rename to the convention and merge duplicates, keeping the links to interdependencies intact.
- Verify TPSP legal names against contracts and the sources above.
- Re-run your BIA and interdependency reports and read them as an examiner would.
Conclusion
Clear BCM reports start with clear record names. Name functions as work, resources as tools, and providers as legal entities, and spell out every acronym. When those three lists are named consistently, the interdependency analysis the FFIEC expects becomes something a reader can follow, and the examiner reads the BIA the way your team meant it.
References
- Federal Financial Institutions Examination Council, IT Examination Handbook: Business Continuity Management booklet, November 2019, Section III.A (third-party hosted copy; official version on the FFIEC IT Handbook InfoBase).
- Federal Deposit Insurance Corporation, FIL-71-2019: Updated FFIEC IT Examination Handbook – Business Continuity Management Booklet, November 14, 2019.
- Board of Governors of the Federal Reserve System, FDIC, and Office of the Comptroller of the Currency, Interagency Guidance on Third-Party Relationships: Risk Management, June 2023 (Federal Reserve SR 23-4 copy).
- APQC, Process Classification Framework (PCF) Business Rules, 2018.
- Plain Language Action and Information Network, Federal Plain Language Guidelines, March 2011, Revision 1, May 2011, Sections III.a.1, III.a.2, and III.a.3.
- U.S. Small Business Administration, Choose your business name.
- Global Legal Entity Identifier Foundation, Level 1 Data: Who Is Who.
- U.S. Securities and Exchange Commission, Search Filings (EDGAR).
