Managed IT and Cybersecurity for Columbus Fintech, Healthtech and Insurtech

What does the security review actually ask you to produce?

The questionnaire reads like an opinion survey and behaves like a document request. Nearly every row resolves to an artifact somebody has to be able to hand over: a policy with an approval date on it, an export, a report, a roster, a name. Answering yes takes a second. Answering yes with the file attached is the entire exercise. The questions themselves repeat from buyer to buyer. What matters before a deal reaches this stage is what each one is asking you to produce.

Take them in the order they usually break. “Who is responsible for information security at your organization” wants a named person with that responsibility written down somewhere, and at an early-stage company security is normally distributed across whoever configured each system first. “Do you maintain written security policies” wants documents with version dates and an approval on them. The conventions your team follows and everybody already knows do not answer it. “Do you perform periodic access reviews” wants the review itself: a list of every account that can reach production, a date, and the name of the person who went through it line by line. That is usually the first time anyone has produced the list, and the first time anyone notices the contractor from last spring, the service account wired into the analytics pipeline, and the shared administrator login two people use. “How long do you retain security logs” wants a retention period you chose on purpose, and platform defaults are usually shorter than the window a reviewer asks you to cover, which is a setting nobody can change retroactively. “When was your last penetration test” wants a report; a vulnerability assessment is different work producing a different document, so read which of the two the row is naming. Penetration testing and a vulnerability assessment are different engagements producing different documents, and they are scoped and scheduled separately for that reason.

Then there is the row that cannot be answered late. SOC 2 is not a law, and no statute requires it. It is an attestation defined by the AICPA and performed by an independent CPA firm, and the reason it is on the questionnaire is that your buyer decided to ask for it. What separates it from every other row is time. A type 1 report speaks to controls as of a single date. A type 2 (your buyer will write it Type II) speaks to whether controls operated across a period, which means the period has to be behind you before an auditor has anything to report on. In practice that is measured in months rather than weeks. The urgency of the deal does not shorten it, and it is not work you can start when the questionnaire lands and finish before it is due. ISO 27001 sits in the same category: a standard your buyer asks you to certify against. It is not a legal duty, and no one issues the certificate on a sales timeline.

Which is why the work has to start before the deal that needs it. Our Virtual CISO and Compliance-as-a-Service engagements are built for this reader specifically: startups and scale-ups, lean and fast-moving teams, companies selling to enterprise buyers. They run in that order. A personalized gap analysis against the controls you are actually being asked about. Evidence tracking, so the artifacts exist before somebody asks for them. Control maintenance, so what was true in March is still true in September, because a coverage report is only accurate against the inventory it was run from. Then renewals worked out of a file that was already being kept. One boundary is worth stating plainly, because this industry blurs it constantly. TTS Cyber is not a CPA firm and does not issue SOC 2 reports. An independent auditor performs the examination and issues the report. What we do is put the controls in place and keep the evidence current, so that examination has something to look at and the next questionnaire is a retrieval job rather than a reconstruction.

SOC 2, ISO 27001 and CMMC are the frameworks that work is built around, from an initial gap analysis through evidence tracking and ongoing renewals. That describes a service TTS Cyber delivers to clients, separate from TTS Cyber’s own compliance status. TTS Cyber has completed its own SOC 2 Type II examination; that fact is about TTS Cyber, not about a client engagement, and it does not extend to ISO 27001 or CMMC, which stay unaddressed here.

Which party is the regulated entity, and which is the vendor being reviewed?

Almost everything written about compliance in these industries is written for the institution: the practice under HIPAA, the agency under Ohio’s insurance data security chapter, the credit union under NCUA. This page is written for the company selling to that institution. The distinction changes what compliance is for. An institution’s deadline comes from a regulator. A vendor’s arrives attached to a signature page, and the diligence room at a Series A or B asks the same questions from the other direction. The review has the shape of a rulebook and the timing of a sales cycle.

The pass-through is written into the rules themselves, which is why the questions look so similar from one buyer to the next. Under Appendix A to NCUA’s Part 748, section III.D gives a federally insured credit union three duties over its service providers: exercise due diligence selecting them, require appropriate safeguards by contract, and monitor them where its risk assessment calls for it, reviewing audits or equivalent test results. The FTC Safeguards Rule requires a financial institution it covers to take reasonable steps to select providers capable of maintaining appropriate safeguards, to require those safeguards by contract, and to periodically assess them based on the risk they present. And where a cybersecurity event happens in a system a third-party service provider maintains, section 3965.03(C) of the Ohio Revised Code requires the insurance licensee to take the investigation steps itself or make reasonable efforts to confirm and document that the provider did. Read those three together and the questionnaire stops looking arbitrary. None of the three names SOC 2, and none of them names any other report. What they do is put your buyer under duties to select, to contract and to assess, and a buyer discharging those duties decides for itself what evidence it will accept. That is why the row asking for independent testing results is usually where a SOC 2 report or a penetration test report gets handed over. “Confirm and document that the provider did” is why the incident response and notification section runs longer than you expected, and why it asks how fast you would tell them.

Some duties do land on the vendor directly, and which ones depends on what the product touches rather than what the company calls itself. None of that is a question to answer from a summary. The sections themselves are the place to read it.

Which of these rules bind the vendor, and which arrive through the customer?

Three questions decide how much of this lands on the vendor directly. Does the product touch protected health information on behalf of a covered entity. Is the company in the business of activities the Gramm-Leach-Bliley Act treats as financial. Does it serve Ohio insurance licensees. None of the three is the question a security questionnaire asks, because that questionnaire is written out of the buyer’s rulebook rather than the vendor’s. The three are worth separating, because which hat a company wears decides whether a buyer’s diligence is a courtesy extended to close a deal, or the discharge of a duty that already runs to the vendor.

Start with healthtech, where the answer is most often yes. A product that creates, receives, maintains or transmits protected health information on behalf of a covered entity is doing business associate work. The Security Rule’s own applicability section, 45 CFR 164.302, applies those standards to covered entities and business associates alike, so a business associate is directly liable under the Security Rule for what it holds. The covered entity needs a written business associate agreement from the vendor, giving satisfactory assurances that the information will be appropriately safeguarded. That agreement runs in both directions. It does not move the practice’s or the health system’s own obligations onto the vendor, because their risk analysis still has to cover their workstations, their email and their network. It also does not shrink the vendor’s. 45 CFR 164.410 requires a business associate to notify the covered entity of a breach of unsecured protected health information without unreasonable delay and no later than 60 calendar days after discovery. And depending on the relationship, a business associate’s discovery can count as the covered entity’s, which is a question the contract settles.

Fintech splits into two duties that founders tend to collapse into one. The first can bind a vendor directly. The Gramm-Leach-Bliley Act directs the Federal Trade Commission to set safeguard rules for companies the law defines as financial institutions, and that definition is broader than holding a charter. An accountant or other tax preparation service that is in the business of completing income tax returns sits inside it at 16 CFR 314.2(h)(2)(viii). Whether the rule reaches a particular company turns on that definition, which is worth confirming against 16 CFR 314.2(h) with counsel rather than assuming in either direction. Where it does reach a company, the FTC Safeguards Rule requires that company to designate a Qualified Individual to oversee the program, to base it on a risk assessment, to encrypt customer information in transit over external networks and at rest, to require multi-factor authentication for anyone accessing any information system, to train its staff, to oversee the service providers who touch that data, and to keep a written incident response plan.

The second fintech duty is not the vendor’s by statute at all. That same rule lands on the bank, the credit union or the preparer being sold to, whose own program has to oversee the service providers who touch that data. Their obligation arrives at the vendor as contract language and as a questionnaire. It is owed because it was signed, and no regulator named the vendor. The practical difference is that it is negotiable before signature and enforceable after.

Insurtech works the same way from a different statute. Ohio Revised Code Chapter 3965 binds a “licensee,” and section 3965.01(M) defines that term broadly: any person licensed, authorized to operate, or registered, or required to be licensed, authorized, or registered, pursuant to the insurance laws of this state. A vendor that holds no license of its own is not the licensee; the customer is. What reaches the vendor is what the chapter still asks of the licensee about systems the vendor runs. Section 3965.03(A) lets an outside vendor or service provider designated to act on the licensee’s behalf do the post-event investigation work, which is why that language shows up in agency and carrier contracts. It does not let the work go undone. And where an event happens in a system a third-party service provider maintains, section 3965.03(C) requires the licensee to take those steps itself or make reasonable efforts to confirm and document that the provider did. Read from the vendor’s side of the table, that means an agency has to be able to document what its provider did, in the same week it is working its own investigation and notification obligations under sections 3965.03 and 3965.04, and dealing with the same incident.

So the three hats give three different answers to one question. Healthtech touching PHI has a duty with its own name on it. Fintech may have one, depending on a definition worth confirming rather than guessing. Insurtech usually does not, and instead has a customer holding a duty that cannot be satisfied without documentation from the vendor. In the first case the buyer’s diligence is a vendor evidencing something it already owes. In the third it is a vendor evidencing something the buyer owes. The artifact is the same either way: a control that was actually configured, and a record showing it was configured on the day someone asked. And note what is not on this list. Neither SOC 2 nor ISO 27001 appears anywhere in it, because neither is a law. They are on the table because a buyer asked, and the report or the certificate comes from an independent firm rather than from us.

Who had access to customer data in March, and can you show it?

There is no office to secure, and that turns out to be a smaller simplification than it sounds. There is no domain controller, no directory every device joins, and no group membership that means anything on its own. The laptop was shipped to whoever needed it. Production is reached from that laptop, over the internet, by someone who might be an employee, a contractor on a two-month engagement, or a fractional operator working with three other companies the same week. The code lives with one provider, the infrastructure with another, and the rest of the company runs on a dozen platforms that each have their own idea of what an admin is. What a network perimeter used to do, identity now does. A buyer’s security review asks who can reach customer data, what they can do with it, and how you know. Every one of those questions resolves into accounts. So accounts are where the work starts.

The first deliverable is a list, and most teams have never written it down in one place. Every system that holds customer data or can reach it: the cloud accounts, the code repositories, the deployment pipeline, the data warehouse, the error tracker and the log aggregator that quietly hold real records inside captured payloads, the support desk, the analytics tool, billing. Against each line goes a named human owner rather than a team name, the current admins, how access is granted, how it is removed, and whether the system authenticates through your identity provider or carries its own separate username and password. That last column decides how much of everything after it can be handled centrally and how much stays a manual checklist. The same list is what an enterprise security review and an investor’s diligence request are both reaching for in different words, so it gets built once and answers both.

Enforced is a different word from available. Enforced means the policy covers every account, and that you can produce the list of accounts it does not cover. That list always exists at a startup, and it is usually short and uncomfortable: the root account created on day one under a founder’s personal email, the service account the pipeline authenticates with, a shared login for a vendor portal that bills by seat, a contractor invited straight into a repository outside the identity provider. Each of those gets a reason written next to it, a named owner, a compensating control and a review date, which is the difference between an exception and a gap. Founder-held root accounts are their own case: kept separate from the daily login of the person who holds them, given the strongest second factor the platform supports, and used only for the handful of tasks that actually require them. Where the FTC Safeguards Rule reaches a fintech, it requires multi-factor authentication for anyone accessing any information system, and permits a reasonably equivalent or stronger control in its place only where the Qualified Individual reviews and approves it in writing (16 CFR 314.4(c)). Whether the rule reaches a particular company turns on the definition of a financial institution at 16 CFR 314.2(h), which is worth confirming against the text rather than assuming in either direction.

Offboarding is where a cloud-only company is most exposed, because there is no single account to disable. Shutting off someone’s mail on their last day does nothing to a cloud console user, a personal account that was invited into your code organization, a billing login, or a shared workspace seat at a vendor. So the work starts at hire rather than at termination: a per-role, per-system list of every account the role needs, written down at the moment each one is created, then run in reverse on the last day with a date and a name against each line. Movers need the same treatment and get it far less often. The engineer who spent two weeks on a migration and still holds production read access a year later is the ordinary version of this. Contractors and fractional staff get access with an end date on it from the start, because the engagement has one. Where a platform can join your identity provider, joining it shortens the checklist; where it cannot, it stays on the checklist with an owner against it. Managed IT covers the onboarding and offboarding mechanics and the laptops behind them, and where your identity provider is a Microsoft tenant, cloud IT services cover the tenant side of it.

Who had access to customer data in March is a question asked in the past tense, and today’s user list does not answer it. Two things have to already exist. The first is logging that outlives the period being asked about: administrative activity in the cloud accounts, sign-in and multifactor events from the identity provider, repository and pipeline audit history, and the admin action logs inside whichever platforms hold customer records. All of it is retained for a period you set and can defend, and kept somewhere that is not only inside the account that produced them. The second is a dated record of access itself: an export of each system’s user list, read name by name on an interval by someone who knows what those people actually do, with additions, removals and exceptions recorded as they happen. An access review that leaves no artifact behind is a meeting. Doing it this way means the answer gets produced from a file rather than rebuilt under someone else’s deadline.

SOC 2 and ISO 27001 sit on top of all of that, and neither one is a law. Both are in your path because a buyer asked for them, which is the same preparation-and-upkeep work described above, applied to this list specifically. A Type II report describes controls across a period of time rather than at a single date, so the calendar matters more than most founders expect, and starting the record early is what shortens everything downstream. If you do not know where the company stands today, the Security Analysis at outreach.ttscyber.com/analysis is $349, independent of any purchase, with findings mapped to 38 compliance frameworks.

How fast would you actually know, and who decides it is an incident?

Everything above is about producing an artifact somebody else reviews, on their schedule. This is about an ordinary Tuesday: something in a log looks wrong, and somebody has to decide, in the moment, whether that is nothing or the start of an actual incident. At most companies this page is written for, the honest answer is whoever happens to be looking, whenever they happen to be looking, which is a capability gap rather than a paperwork gap.

Two things have to exist before that decision can be made well. The first is the same logging a security review already asks about: administrative activity, sign-in and multifactor events, and the admin actions inside whichever platforms hold customer data, kept somewhere that outlives the account that produced it. The second is a named person with the authority to make the call and run what follows it, which is a different thing from a policy document naming a role. Incident response ownership is one of the responsibilities our Virtual CISO engagements take on directly: a person accountable for deciding whether what got noticed is a real incident, and for running the response once it is.

Coverage windows are worth being honest about rather than assumed. TTS Cyber’s Network Operations Center monitors during business hours. Separately, under a signed service agreement, you can report a whole-company outage at any hour, and TTS Cyber aims to respond within one hour. The fix itself can take longer. Watching for trouble and answering a report are two different commitments. An incident does not wait for business hours, so it is worth knowing in advance which hours each commitment covers.

Once something is confirmed as real, ownership extends past the technical response. A buyer’s diligence and a cyber insurance policy both ask who is accountable for reporting an incident, on what timeline, and to whom, and reporting to insurers or to a board is part of the same Virtual CISO scope, rather than a separate thing bolted on afterward.