Cybersecurity for Regulated Industries in the Chicago Area

RJ2 Technologies is a managed IT and cybersecurity provider in Deer Park, Illinois, founded in 1998. The company runs security and compliance work for small and mid-market businesses across the Chicago metropolitan area, including private equity and financial services firms, insurance brokerages, engineering firms and manufacturers, as well as accounting and law firms. That work covers managed detection and response, monitoring, multi-factor authentication, email security, zero trust access and penetration testing. RJ2 also supports clients preparing for SOC 2 Type 2, ISO 27001 and CMMC requirements, with audit assistance through a specialist partner under a separate agreement. Engineers working downtown use a drop-in space at 333 S. Wabash Ave., Suite 2700, which is a working space rather than a staffed office.

Why do attackers go after regulated businesses specifically?

Because regulated businesses hold concentrated, verified, current personal and financial data, and because they are under pressure to keep operating. A CPA firm in March has every client’s Social Security number, bank routing details and full income picture in one system, and it cannot afford three days offline. That combination, high-value data plus low tolerance for downtime, is what makes a firm a target and what makes it likely to pay.

The size of the firm is not the protection people assume it is. Most attacks that reach small and mid-market firms are not targeted at that firm by name. They are opportunistic, run at scale against exposed remote access, unpatched edge devices and credentials bought from a broker. A twelve-person practice and a twelve-hundred-person company get scanned by the same tooling on the same day.

Three patterns account for most of what actually lands:

• Credential theft and business email compromise. An attacker gets into a mailbox, reads for a few weeks, learns how the firm talks about money, then redirects a wire or a client payment. No malware involved, which is why endpoint tools alone do not catch it.
• Ransomware with data theft first. The current pattern is to copy the data out before encrypting anything, so that a clean restore from backup does not end the negotiation. This is why a regulated firm’s backup strategy and its breach notification obligation are the same conversation.
• The third party. The tax software vendor, the practice management host, the outsourced bookkeeper. Regulated firms are increasingly held responsible for the security of the vendors holding their client data, and most of them have never inventoried who those vendors are.

What does a cyber insurance questionnaire actually ask for, and what happens if you answer wrong?

Cyber insurance applications ask for specific technical controls, not general assurances, and the answers you give become part of the insurance contract. A wrong answer is not a paperwork problem. It gives the carrier grounds to rescind the policy or deny the claim, and that determination is usually made after an incident, when the coverage is the only thing left.

Applications vary by carrier, but the controls asked about are now fairly standard across the market:

• Multi-factor authentication, asked separately for email, for remote access and VPN, for privileged and administrative accounts, and for remote access to backups. Answering yes for email and no elsewhere is a different answer than answering yes.
• Endpoint detection and response, deployed on what percentage of endpoints and servers, and whether it is monitored around the clock by people or only generating alerts into a mailbox nobody reads on a Saturday.
• Backups, specifically whether they are offline, immutable or otherwise separated from the production domain, how often a restore is actually tested, and whether the backup admin account is separate from the domain admin account.
• Email filtering and phishing controls, including whether SPF, DKIM and DMARC are configured and enforced.
• Patching cadence, usually asked as days to patch a critical vulnerability, and whether any end-of-life operating systems remain in the environment.
• Remote Desktop Protocol exposure, meaning whether RDP is reachable from the open internet. This one is close to disqualifying at most carriers.
• Privileged access management, whether administrators use separate accounts and whether local admin rights have been removed from standard users.
• Security awareness training and phishing simulation, with a stated frequency.
• A written incident response plan with named contacts, and whether it has been exercised.

What happens if you answer wrong

The application is signed by an officer of the firm and it is incorporated into the policy. In most policy forms the answers are representations, and in some they carry warranty language, which is stronger. A material misstatement gives the carrier a route to rescind the policy from inception, meaning it is treated as never having existed, rather than simply denying one claim.

This has been litigated. In 2022, Travelers filed suit in federal court in the Central District of Illinois seeking rescission of a cyber policy, alleging the insured’s application had represented that multi-factor authentication was in use across the environment when it was not. The matter resolved with the policy rescinded by agreement. The point for a Chicago-area firm is not the specific case. It is that carriers now treat the MFA question as a coverage condition rather than a preference, and they have shown willingness to litigate it.

Two practical consequences:

1. Whoever signs the application must not be the only person who reads it. The controls questions are technical. They should be answered by, or verified against, whoever actually administers the environment, before an officer signs.
2. The honest answer is safer than the optimistic one, even when it costs you a discount. A “no” with a remediation date is underwritable. A “yes” that turns out to be a “mostly” is a coverage fight during the worst week of the firm’s year.

RJ2 provides the information and suggestions behind the technical answers and helps close the gaps the questionnaire exposes. The client completes and signs the application.

What does SOC 2 require from IT specifically?

SOC 2 does not hand you a checklist of technical controls. It is an audit, performed by an independent CPA firm, against the AICPA Trust Services Criteria, and the criteria describe outcomes the organization must achieve rather than products it must buy. Your organization defines the controls it uses to meet each criterion, and the auditor tests whether those controls existed and operated. That is why two companies can both hold a clean SOC 2 report and run very different environments.

What that means in practice is that IT is not asked to install anything in particular. IT is asked to produce evidence, repeatedly, over a defined window.

Type I versus Type II. A Type I report says the controls were designed appropriately as of a single date. A Type II says they operated effectively across an observation window, commonly three to twelve months. Type II is what most enterprise customers and most procurement teams are actually asking for, and it is the one that changes how IT has to work, because it cannot be assembled the week before.

The security criteria are mandatory. Availability, confidentiality, processing integrity and privacy are elected based on what the business commits to its customers. Most first-time reports scope to security alone, sometimes with availability and confidentiality added.

The evidence IT typically has to produce

• Access provisioning and deprovisioning records. Who was granted what, approved by whom, and proof that leavers lost access within the window the policy states. Terminated-user access is one of the most commonly failed items in a first Type II.
• Periodic access reviews, usually quarterly, with the reviewer’s sign-off retained.
• Multi-factor authentication on administrative access and on remote access, with configuration evidence rather than an assertion.
• Change management. Tickets showing that changes were requested, reviewed, approved and deployed, with a separation between the person who wrote a change and the person who approved it.
• Vulnerability management. Scan output, a documented remediation standard by severity, and evidence that findings were closed inside it.
• Logging, monitoring and alerting. Not just that logs exist, but that alerts route to someone, that someone acknowledged them, and that log retention meets the stated policy.
• Backup and restore. Backup success reporting plus evidence of an actual restore test, with a date and a result.
• Incident response. A written plan, and tickets for real incidents showing the plan was followed, including ones that turned out to be nothing.
• Vendor and subservice organization management. An inventory of vendors touching in-scope data, and review of their reports or security posture.
• Risk assessment, documented, annual, with the identified risks traced to controls.
• Security awareness training completion records for every in-scope employee.

The part that catches firms out

SOC 2 is a documentation discipline as much as a technical one. Most of the failures in a first Type II are not missing tools. They are a control that exists but was performed inconsistently, or performed and never recorded. If the access review happened in a hallway conversation, it did not happen.

What is the difference between being compliant and being secure?

Compliance is a statement about a point in time, made against a defined control set, usually to satisfy someone outside the business. Security is a property of the environment that either holds or does not hold on any given Tuesday. They overlap, they are not the same, and a firm can pass an audit in the morning and be compromised that afternoon without either fact being surprising.

Three concrete ways they come apart:

Frameworks set a floor, and floors get old. A control set written to be achievable by a wide range of organizations lands at the level most of them can reach. Attackers do not stop at that level. Meeting the standard means you have cleared the bar the standard set, not that you have cleared the bar an attacker sets.

Scope is narrower than your business. A SOC 2 report covers defined systems. An examination covers the records the examiner asked for. The firm’s actual attack surface includes the personal phone with mail on it, the twelve-year-old machine running the plotter, the vendor’s remote access tool nobody remembers approving, and none of those may be in scope.

Evidence is not the same as effect. You can hold a complete set of quarterly access review sign-offs and still have a shared administrator password in a spreadsheet, because the review confirmed the accounts on the list and the shared credential was never on the list.

The useful way to hold both: use the framework as the agenda and not as the goal. Compliance work is genuinely valuable, because it forces inventory, forces documentation, and gives you a reason to fix things the business would otherwise defer. Treat the report as a byproduct of running the environment properly, not as the thing being produced. Firms that invert that relationship end up with a clean report and a real problem.

The honest short version for a managing partner or CFO: compliance protects you from the regulator and the customer’s procurement team. Controls protect you from the attacker. You need both, and only one of them is on a deadline.

What should a small regulated firm have in place at minimum?

Below is the baseline. It is not a maturity model or a roadmap. It is the set of controls that appears on almost every cyber insurance application, in almost every framework a small regulated firm encounters, and in almost every incident report explaining how the attacker got in.

Identity, first, because this is where most incidents start

• Multi-factor authentication on every account, with no exceptions for executives, and specifically on email, remote access, VPN, administrative accounts and any cloud application holding client data
• Separate administrator accounts, with day-to-day work done from a standard account
• Local administrator rights removed from standard user machines
• A documented offboarding process that disables access the same day, including the applications outside your main directory

Endpoints and email

• Endpoint detection and response on every workstation and server, monitored by people rather than only generating alerts
• Email filtering, plus SPF, DKIM and DMARC configured and set to enforce rather than to monitor
• Automatic patching with a stated deadline by severity, and nothing end-of-life still in production

Data and recovery

• Backups that are offline, immutable, or otherwise not reachable with production domain credentials
• A restore actually tested on a stated cadence, with the result written down
• Encryption in transit and at rest on anything holding client or regulated data, including laptops

The paperwork that is also a control

• A written information security program or plan, matching what the environment actually does
• A written incident response plan with named people, phone numbers that work outside business hours, your insurer’s notification number, and outside counsel
• An annual written risk assessment
• An asset inventory, including cloud applications and the data each one holds
• A vendor list covering everyone who touches client data, with their security posture reviewed
• Security awareness training with phishing simulation, on a stated frequency, with completion recorded

The one people skip

• Logging, with retention long enough to reconstruct what happened. Median attacker dwell time is measured in weeks. Thirty days of logs will not tell you what you need to tell a regulator, and the notification clock starts whether or not you can answer.

If a firm has the identity block and the recovery block and nothing else, it is in better shape than most of its peers. If it has the paperwork and not the identity block, it is compliant and exposed.

Which regulation or framework applies to your industry?

The short answer is that most regulated small firms are covered by more than one, and the one they know about is rarely the strictest one that applies to them. This table is the map. The sections below it go one level deeper on each.

The industry sections

Cybersecurity for CPA and accounting firms

What they hold that attackers want. Complete, verified financial identities. Names, Social Security numbers, dates of birth, bank routing and account numbers, employer information, dependents, prior-year returns. A tax return is a more complete identity dossier than almost anything else a small business stores, and an accounting firm holds hundreds or thousands of them in one system. The timing pressure is the second half of the problem. A firm that loses access to its systems in the first week of April has no slack anywhere in its calendar.

Which framework applies. Accounting firms that prepare returns for a fee are treated as financial institutions under the Gramm-Leach-Bliley Act, which puts them under the FTC Safeguards Rule, 16 CFR Part 314, in its amended form. That rule is prescriptive in a way many firms do not expect. It requires a designated qualified individual responsible for the program, a written risk assessment, access controls, encryption of customer information in transit and at rest, multi-factor authentication for any individual accessing any information system holding customer information, secure disposal, change management, logging of authorized user activity, a written incident response plan, oversight of service providers, and an annual written report to the board or equivalent governing body. Since May 2024 the rule also requires notifying the FTC of a security event affecting 500 or more consumers within 30 days. Alongside it, IRS Publication 4557 and the written information security plan requirement apply, and the IRS now asks about a data security plan at PTIN renewal.

The one control most often missing. Multi-factor authentication on the hosted tax application and on remote access into it. Firms very often enable MFA on Microsoft 365, consider the job done, and leave the hosted tax platform, the remote desktop environment and the document portal on a password alone. Those are precisely the systems holding the customer information the rule is written about. The Safeguards Rule allows the qualified individual to approve reasonably equivalent or more secure controls in writing instead, but that approval has to exist as a document, and in most firms it does not.

Cybersecurity for financial advisors and wealth management firms

What they hold that attackers want. Account numbers, custodian credentials, holdings, transfer authorizations and a client base selected for having money. The high-value attack against an advisory firm is not encryption, it is impersonation: an attacker inside the advisor’s mailbox watching how the firm handles distribution requests, then sending one. The firm’s own systems may never be touched.

Which framework applies. SEC Regulation S-P, materially amended in 2024, is the center of it. The amendments require covered firms to maintain a written incident response program, and to notify affected individuals as soon as practicable and no later than 30 days after becoming aware that unauthorized access to sensitive customer information has occurred or is reasonably likely to have occurred. Compliance dates were staged, with smaller entities brought in during 2026. Regulation S-ID requires an identity theft prevention program with defined red flags. Adviser books and records obligations govern retention and reproduction of electronic records, including business communications on messaging platforms. Broker-dealers carry FINRA obligations on top. State registration adds a state layer for advisers below the SEC threshold.

The one control most often missing. A written incident response program that can actually produce a notification decision inside 30 days. Firms have security tooling; what they do not have is the documented path from “something happened” to “we have determined which clients are affected and we are notifying them,” with named owners and a clock. The 30-day obligation runs on awareness, not on completing your investigation. A close second is oversight of the third parties holding client data, which the amended rule reaches directly.

Cybersecurity and IT support for law firms

What they hold that attackers want. Everything a client would not want disclosed, concentrated and organized. Deal documents before announcement, litigation strategy, settlement figures, personnel investigations, IP filings, and client trust account details. Law firms are also a route into other organizations: compromising one firm can reach the confidential information of every client it serves, which is why firms handling M&A, IP and regulatory work are targeted well out of proportion to their size.

Which framework applies. Not a regulator in the usual sense. Professional responsibility. ABA Model Rule 1.1, comment 8 makes competence include understanding the benefits and risks of relevant technology. Model Rule 1.6(c) requires reasonable efforts to prevent unauthorized disclosure of client information. ABA Formal Opinion 477R addresses securing communication of protected client information, and Formal Opinion 483 sets out the obligations after a breach, including the duty to notify current clients whose confidential information was compromised. Illinois has adopted the corresponding rules of professional conduct. On top of that sit client outside counsel guidelines, which for corporate clients increasingly carry hard security requirements, sometimes including a right to audit and sometimes requiring SOC 2 or ISO 27001. In practice the client’s procurement team is a stricter regulator than the bar.

The one control most often missing. Least privilege inside the document management system. Firms secure the perimeter and then give every user access to every matter, so one compromised account exposes the whole library rather than one client’s file. Matter-level access control is the difference between a contained incident and a firm-wide notification obligation to every client. The runner-up is multi-factor authentication on webmail, which is often the one place an exception was granted for a senior partner.

Cybersecurity for insurance brokers and agencies

What they hold that attackers want. Applications and policy files, which is to say Social Security numbers, dates of birth, driver’s license numbers, medical information on life and health lines, loss runs, and business financials for commercial clients. Brokers also hold live credentials to carrier portals, which is an access path into systems the broker does not own. And brokers move money, so the wire fraud pattern applies here as directly as it does in accounting.

Which framework applies. The NAIC Insurance Data Security Model Law, adopted by a majority of states, is the operative standard for most brokerages, and it applies based on where you are licensed rather than where you sit. It requires a written information security program based on a risk assessment, a designated responsible person, third-party service provider oversight, an incident response plan, notification to the state insurance commissioner within 72 hours of determining a cybersecurity event occurred, and an annual certification of compliance in states that require it. A broker licensed in several states is bound by the model law in each of the adopting ones. Brokers licensed in New York are also under NY DFS Part 500, which as amended requires multi-factor authentication for all individuals accessing any information system. In Illinois, the Personal Information Protection Act applies to everyone regardless.

The one control most often missing. Multi-factor authentication on the agency management system and on carrier portals. Brokerages secure Microsoft 365 and stop, and the agency management system, the comparative rater and a dozen carrier logins keep running on shared or reused passwords. Those systems hold the applicant data and they are the ones an examiner asks about. A related gap: shared logins for carrier portals, which make it impossible to answer the “who accessed this” question a 72-hour notification requires.

Cybersecurity for manufacturers

What they hold that attackers want. Two different things, protected two different ways. On the business side: CAD files, process documentation, bills of material, supplier pricing and customer contracts, which are the firm’s actual competitive position. On the plant floor: control systems where the value of the attack is not the data but the stoppage. A manufacturer’s tolerance for downtime is measured in hours of lost production with a dollar figure attached, and attackers price ransoms accordingly.

Which framework applies. It depends on who you sell to. Defense-adjacent manufacturers handling controlled unclassified information fall under DFARS 252.204-7012 and NIST SP 800-171, now enforced through the CMMC program, with requirements phasing into DoD contracts and an assessment score reported in SPRS. Manufacturers with no defense exposure are usually governed by their customers’ contractual security requirements instead, which for automotive and aerospace supply chains can be as demanding as a formal framework and arrive with less warning. ISO 27001 shows up as a customer requirement, and IEC 62443 is the reference standard where operational technology is genuinely in scope. In Illinois, manufacturers using fingerprint or hand-geometry time clocks are under the Biometric Information Privacy Act, which carries a private right of action and has produced very large settlements. That one catches manufacturers more than any other sector here.

The one control most often missing. Network segmentation between the business network and the plant floor. In most small and mid-market plants the machines, the historians and the engineering workstations sit flat on the same network as the office, so a phishing email in accounts payable reaches the line. The second gap is an asset inventory that includes OT, because a great many plants cannot produce a list of what is actually connected, and you cannot segment or patch what you have not counted. RJ2 supports warehouse and manufacturing environments, including low voltage cabling, access controls and surveillance camera systems alongside the IT network, and supports CMMC requirements through a partner that is CMMC certified.

What about healthcare, dental, construction, education, government and non-profit?

The same approach applies in those sectors as well. The shape of the problem is the same in each: identify the regulated or contractually protected data, find the framework that governs it, and close the control gap that framework exposes. What differs is the framework and the specific gap.

• Healthcare and dental. HIPAA Security Rule, which requires a documented risk analysis most small practices have never completed, plus business associate agreements with every vendor touching protected health information.
• Construction. Usually not regulated directly, but bound by owner and general contractor security requirements on larger projects, and heavily exposed to wire fraud on payment applications.
• Education. FERPA for student records, and state student data privacy law. K-12 districts additionally face E-Rate and state reporting obligations.
• Engineering. Client confidentiality and IP protection, plus export control obligations where designs are controlled.
• Government. Contractual and grant-driven security requirements, with CJIS applying wherever criminal justice information is touched.
• Non-profit. Donor financial data and, for many, grant conditions that impose security obligations the organization never budgeted for.

Who should you call for cybersecurity in the Chicago suburbs?

RJ2 Technologies has been based in the Chicago suburbs since 1998, serving businesses across Chicagoland, Rockford and Northern Illinois, southeastern Wisconsin and northwestern Indiana, and nationwide for larger clients with multiple locations. The headquarters at 21660 W. Field Parkway, Deer Park, IL 60010, is the staffed office. The Chicago address at 333 S. Wabash Ave., Suite 2700 is a working space engineers use when they are downtown with a client, rather than a staffed office.

For a security or compliance conversation, corporate is 847-303-1194 and sales is sales@rj2t.com.

Byline

Jeff Dann, Founder and CEO, RJ2 Technologies. Jeff founded RJ2 in 1998 and writes on security, compliance and business risk. He sits on the Board of Directors of the Better Business Bureau of Chicago.