How to prepare for a security audit, regulator review, or board cybersecurity question
Some morning soon, an email is going to land in your inbox asking about your cybersecurity program. It might come from a customer's procurement team requesting an annual audit. It might come from the FTC after a colleague's firm reported a breach. It might come from your state bar's ethics committee following a malpractice complaint. It might come from a board member who just read an article about ransomware and wants to know what your business is doing about it.
The form of the scrutiny varies. The underlying question is the same: what can you produce?
This post walks through four kinds of cybersecurity scrutiny that small and mid-sized businesses regularly face: customer security audits, FTC Safeguards Rule reviews, ABA professional responsibility reviews, and board cybersecurity questions. The post walks through each one and names what the reviewer is actually looking for. The patterns across them are more useful than the specifics of any one type, because the patterns are what let you prepare for all four at once.
What every reviewer is testing for
Before the differences, the shared structure. A cybersecurity reviewer (whether an auditor, a regulator, a bar examiner, or a board member) is asking three things, usually in this order.
First, does the business have a written security program? Verbal commitments, informal practices, and "we have IT for that" don't qualify. A written program is the artifact that lets the reviewer assess what's been committed to.
Second, does the business operationalize what the written program says? A policy on paper that nobody follows is worse than no policy, because it documents a gap between commitment and practice. Reviewers can tell the difference between a written program that's running and a written program that exists only for the binder.
Third, can the business prove the program existed before the scrutiny started? A program adopted last week, in response to the audit notice, doesn't demonstrate the kind of operational maturity reviewers are looking for. Dated documents, version histories, employee acknowledgments with dates, training completion records: these are the artifacts that prove the program has been operating, not just existing.
Once the three questions are answered, the specifics of each reviewer's interest come in. The specifics matter, but they're built on top of the three shared questions, not separate from them.
Customer security audits
The most common scrutiny SMBs face. A customer with a vendor management program (usually a larger enterprise customer or a regulated entity) wants to verify that your business handles their data responsibly. The audit might be triggered by an annual review cycle, by an incident at another vendor, or by a contract renewal.
The audit form varies. Some customer audits are document reviews only: the customer's security team sends a request list and you respond with policies, procedures, and operational artifacts. Some include a video walk-through where your staff demonstrates controls (the access review process in your identity system, a backup restoration test, an incident response tabletop). Some are on-site, especially for manufacturing or regulated-industry vendors with deeper integration. The depth scales with how much of the customer's risk your business carries.
What the auditor is looking for. Three categories of evidence. First, documented controls aligned to a recognized framework (NIST CSF, CIS Controls, ISO 27001, or similar). Second, operational evidence that the controls are working: recent access reviews, completed training records, vulnerability scan results, vendor risk assessments of your own vendors. Third, incident response readiness, including documented procedures and a recent tabletop exercise or similar test.
A specific category worth knowing: supply chain attestation. Many customer audits now include questions about your own vendor risk management. The customer wants to know that the security commitments they're verifying with you also extend to the subprocessors and service providers that handle their data through your business. Documented vendor due diligence (a vendor inventory, vendor risk tiering, and recent vendor reviews) is the artifact that addresses this category. The supply chain attestation question is the one that catches small businesses off guard most often, because it requires evidence that the business has thought about its own vendor risk, not just its direct controls.
What a credible response looks like. A response packet that includes the policy framework, recent operational artifacts (last quarter's access review, current quarter's training records, last vulnerability scan), and a brief narrative explaining the program's structure. The narrative matters: an auditor with limited time will read the narrative carefully and spot-check the supporting artifacts.
What to do when the auditor follows up with "do you have a SOC 2 report?" Some customer audits escalate from a general security review to a specific request for SOC 2 Type 2 attestation, especially in software and technology vendor relationships. SOC 2 is an attestation framework (separate from the safe-harbor frameworks earlier in this post), conducted by independent CPA firms, and not something a documented security program produces on its own. If the customer requires SOC 2 specifically, the honest answer is either to provide the report (if your business has one) or to explain the program's framework alignment and offer to revisit SOC 2 at the next contract cycle. The documented program supports the framework alignment story; SOC 2 attestation is a separate investment.
What to prepare in advance. A customer audit response template populated with your standard answers, mapped to the framework you've adopted. Most customer audits ask substantially the same questions; building the response file once and adapting it for each audit saves the work of re-inventing answers under deadline pressure.
FTC Safeguards Rule reviews
If your business is a non-banking financial institution subject to the Gramm-Leach-Bliley Act, the FTC Safeguards Rule applies. The rule was codified at 16 CFR Part 314, expanded substantially in 2021, and amended again in 2023 to add breach notification requirements (effective May 13, 2024).
The FTC's enforcement authority is broad. The agency can review your program in response to a complaint, in connection with a reported breach, or as part of a broader industry sweep. Covered businesses include mortgage brokers, tax preparation firms, motor vehicle dealers, payday lenders, finance companies, investment advisors not registered with the SEC, and a number of other categories.
What the FTC is looking for. A written information security program with the nine elements the rule requires. The elements include: a designated Qualified Individual responsible for the program, a written risk assessment, encryption of customer information in transit and at rest, multi-factor authentication for access to customer information, regular monitoring and testing of safeguards, security awareness training for personnel, oversight of service providers, an incident response plan, and (for entities with information on 5,000 or more consumers) annual reporting to those in control of the institution. Entities with information on fewer than 5,000 consumers are exempt from some of the elements but not all.
What a credible response looks like. A complete written information security program that addresses each of the nine elements (or the seven applicable to smaller entities), with named documents, dates of adoption, and evidence of operationalization. The Qualified Individual must be named; the risk assessment must exist as a written document; the encryption and MFA implementations must be demonstrable.
What to prepare in advance. The written information security program itself. The rule is specific about elements; a program that doesn't address each one creates exposure during a review. Small CPA firms preparing tax returns are within scope of the rule and often discover this during their first encounter with it; preparing the documented program before an FTC inquiry surfaces the gap is the substantive work.
ABA professional responsibility reviews
If your business is a law firm, your professional responsibility obligations include cybersecurity. Three ABA touchstones organize the expectation.
Model Rule 1.1, Comment [8]. Adopted in 2012 as part of the ABA's "technology amendments," Comment [8] states that a lawyer's duty of competent representation includes keeping abreast of "the benefits and risks associated with relevant technology." Cybersecurity is now part of technology competence by widespread interpretation. A lawyer who can't explain how the firm protects client data may fall short of the competence duty.
Model Rule 1.6(c). Also adopted in 2012, this rule requires a lawyer to "make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client." The standard is "reasonable efforts," not perfect protection; what counts as reasonable depends on the sensitivity of the information and the available safeguards.
ABA Formal Opinion 477R (May 2017). Titled "Securing Communication of Protected Client Information," Opinion 477R provides a seven-factor framework for evaluating cybersecurity needs in any given engagement. The factors include the sensitivity of the information, the cost of additional security measures, the likely impact of disclosure, and the client's expectations. The opinion replaced an earlier 1999 opinion that had concluded unencrypted email was generally acceptable; 477R is more cautious, requiring lawyers to assess the matter rather than rely on a default.
ABA Formal Opinion 483 (October 2018). Titled "Lawyers' Obligations After an Electronic Data Breach or Cyberattack," Opinion 483 addresses what a lawyer must do after a breach is detected or suspected. The opinion requires lawyers to act reasonably and promptly to stop the breach and mitigate damage, conduct a post-breach investigation to determine what was compromised, and notify current clients under Model Rule 1.4 if the breach involves "material client confidential information" or significantly impairs the lawyer's ability to perform the engaged legal services. The opinion's "reasonable efforts" standard is fact-specific rather than strict liability: a lawyer who took reasonable preventive efforts isn't ethically responsible for a breach that happens despite those efforts. The opinion recommends developing an incident response plan as a recommended preparation. For former clients, the opinion notes that Rule 1.9(c) doesn't create an ethical duty to notify, but statutory obligations under state breach notification laws may still apply.
ABA Formal Opinion 512 (July 2024). The ABA's first formal guidance on generative AI in legal practice. It addresses the use of GenAI tools (whether general-purpose or legal-specific) and requires lawyers to maintain technology competence, supervise the use of these tools, protect client confidentiality, and verify AI-generated content. Firms using GenAI tools fall within the scope of 512 even if they haven't formally adopted the tools.
What a state bar reviewer or malpractice insurer is looking for. Documented procedures showing the firm thought through the technology-competence duty: a written information security policy, documented vendor management for technology vendors, employee training on security awareness, and (for firms using GenAI) policies on AI tool use. The 477R seven-factor framework can be applied at the engagement level, but it's most credible when supported by firm-wide documentation.
What to prepare in advance. A written information security policy that explicitly addresses Model Rule 1.1 technology competence, Model Rule 1.6(c) reasonable efforts, and the 477R framework's application within the firm. A vendor management procedure that documents how the firm assesses technology vendors. An AI use policy if the firm uses GenAI tools.
Board cybersecurity questions
Board members of any business (from a small advisory board for a 30-person company to a formal board of directors at a 200-person firm) have started asking cybersecurity questions. Ransomware, customer breach disclosures, regulator enforcement actions, and high-profile incidents at other companies have made cybersecurity a recurring board agenda item.
The board scrutiny is different from the other three in an important way. Customer audits, FTC reviews, and bar examinations all have specific frameworks the reviewer is applying. A board member usually doesn't have a framework; they have a general concern, often triggered by recent news, and they're asking the business to explain itself.
What the board is looking for. A clear, non-technical answer to what amounts to: "Are we doing what a reasonable business of our size should be doing?" The answer needs to be specific enough to demonstrate the business has thought about cybersecurity seriously, general enough not to confuse a non-technical audience, and honest about gaps that remain.
What a credible response looks like. A brief written summary of the program (one or two pages), plus a verbal narrative that names the framework alignment, the recent operational milestones, and any major changes in the threat environment that affect the business. A board member asking the question doesn't want a 50-page audit report; they want to know that the business has a program, that the program is running, and that someone is paying attention.
What to prepare in advance. A quarterly compliance health check, the kind of document a board member can read in five minutes. The health check should include current framework alignment, recent control reviews (access, vulnerability scanning, training), incident response readiness, and a brief forward-looking section on planned changes. Updating the health check quarterly means a board question never finds the business unprepared.
The pattern across all four
All four review types come back to the same three questions: is there a written program, is it being operationalized, and can the business prove both before the scrutiny started. The specific frameworks differ (CIS or NIST for customer audits, the FTC's nine elements for Safeguards Rule reviews, the ABA opinions for law firms, plain-language program summaries for boards), but the underlying requirement is documentation that demonstrates an operating program.
The practical implication: the work of preparing for any one of these reviews is mostly the work of preparing for all of them. A documented program aligned to a recognized framework, operationalized through dated procedures and employee acknowledgments, and reviewed quarterly through a compliance health check, will support a customer audit response, an FTC inquiry, a state bar review, and a board question with substantially the same artifacts.
The artifacts that get used in each review will differ. The customer auditor wants the detailed control mapping; the FTC wants the nine elements explicitly addressed; the bar examiner wants the 477R seven-factor analysis applied to firm practice; the board wants the one-page health check. But the underlying program is shared. The work is done once and serves four kinds of scrutiny.
This is why the program itself is the substantive investment, not the audit response. Businesses that build documentation in response to each audit are perpetually behind. Businesses that build the documented program first and then map it to each reviewer's framework are perpetually ready.
If you'd rather not build the documented program from scratch, TACSOP includes the policies, procedures, and operational artifacts needed to align with CIS Controls Implementation Group 1, plus a Quarterly Compliance Health Check template, customer audit response framework, and stakeholder communication templates for board-level reporting. The kit produces the documentation each kind of reviewer wants to see, organized so the same underlying program supports all four kinds of scrutiny. The kit is here. Consult counsel for state bar, regulatory, or other framework-specific legal questions.