Managed IT and Cybersecurity for Columbus Fintech, Healthtech and Insurtech

We’ve outgrown doing IT ad hoc. What does the next stage look like?

At most companies this page is written for, technology decisions get made one at a time, by whoever is closest to the problem when it happens. That works until the company has enough people, systems and customer data that nobody can hold the whole picture in their head.

TTS Cyber’s Co-Managed IT is built for a company at exactly that point: one IT person, or a small team of two to five, that needs more capacity than its headcount provides. TTS Cyber gives that team monitoring and management tools, takes on overflow tickets, covers after hours and vacations, and takes on the security work a stretched team does not have time for.

TTS Cyber’s IT Strategy & Virtual CIO Services address a different gap: nobody senior is looking at the whole technology estate on a schedule. The engagement produces a written IT roadmap and runs on quarterly planning meetings, so decisions about what to fund and when stop getting made in the week something breaks.

Who should own security as we grow?

Security ownership follows the same curve as everything else. Nobody owns it at first, then it lands on whoever is nearest the problem, and at some point the company needs one person accountable for it. Our Virtual CISO work meets a company anywhere on that curve. Some companies have someone doing security part time and need direction and a second opinion. Others have nobody, and the vCISO holds the whole thing.

The role covers:

• Vendor and third-party risk review: who outside the company can reach its data, and what they can do with it.
• Ownership of the incident response plan.
• The security reporting a cyber insurer or a board asks for.

None of that waits for an audit. It is the ordinary maintenance a security program needs as the company grows. It is also what a buyer’s security review or an investor’s diligence request ends up asking for, usually without warning.

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

There is no office to secure, no directory every device joins, and no group membership that means anything on its own. Laptops ship to whoever needs them. Production is reached over the internet by employees, short-term contractors and fractional staff. 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.

So the first deliverable is a list of every system that holds or can reach customer data:

• The cloud accounts, code repositories and deployment pipeline.
• The data warehouse.
• The error tracker and log aggregator, which quietly hold real records.
• The support desk, analytics tool and billing.

Against each, write a named human owner, the current admins, how access is granted and removed, and whether it signs in through your identity provider. The same list answers an enterprise security review and an investor’s diligence request.

Enforced multi-factor authentication means the policy covers every account, and you can produce the list of accounts it does not cover. At a startup that list is 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.
• A contractor invited straight into a repository.

Each gets a reason, an owner, a compensating control and a review date.

Offboarding is where a cloud-only company is most exposed, because there is no single account to disable. So the work starts at hire: a per-role, per-system list of accounts, run in reverse on the last day with a date and a name on each line. Contractors get access with an end date from the start.

Answering the question in the past tense takes two things that already exist. One is logs retained for a period you can defend, kept outside the account that produced them. The other is a dated access review, read name by name. Managed IT covers the onboarding, offboarding and laptops, and cloud IT services cover a Microsoft tenant if that is your identity provider.

A buyer sent a security questionnaire. What is it asking us to produce?

It reads like an opinion survey and behaves like a document request. Nearly every row resolves to something you hand over:

• A named person responsible for security.
• Written policies with version dates and approvals.
• A dated access review.
• A log retention period you chose on purpose.
• A penetration test report.

A vulnerability assessment is different work producing a different document, so read which one the row names.

Then there is the row that cannot be answered late. SOC 2 is not a law. It is an attestation defined by the AICPA and performed by an independent CPA firm, and it is on the questionnaire because your buyer asked for it. A Type I speaks to controls as of a single date. A Type II speaks to whether they operated across a period, so the period has to be behind you before an auditor has anything to report on. That is measured in months, not weeks. ISO 27001 sits in the same category.

So the work has to start before the deal that needs it. Our Virtual CISO and Compliance-as-a-Service engagements run in this order:

1. A personalized gap analysis against the controls you are being asked about.
2. Evidence tracking, so the artifacts exist before somebody asks for them.
3. Control maintenance, so what was true in March is still true in September.
4. Renewals worked out of a file that was already being kept.

TTS Cyber is not a CPA firm and does not issue SOC 2 reports. We put the controls in place and keep the evidence current, so the examination has something to look at. Separately, TTS Cyber has completed its own SOC 2 Type II examination.

Which rules bind us directly, and which arrive through our customers?

Most compliance writing is for the institution: the practice under HIPAA, the agency under Ohio’s insurance data security law, the credit union under NCUA. This page is for the company selling to it. Your buyer’s rules require it to choose vendors carefully, require safeguards by contract and check on them, and none of those rules names SOC 2. That is why the questions look so similar from one buyer to the next. What depends on your product is how much lands on you directly:

• Healthtech that touches protected health information for a covered entity is a business associate, directly liable under the HIPAA Security Rule. The business associate agreement does not shrink that. A breach of unsecured protected health information has to be reported to the covered entity without unreasonable delay and within 60 days, and depending on the relationship, your discovery can count as theirs.
• Fintech may be covered by the FTC Safeguards Rule directly. That turns on whether the company meets the rule’s definition of a financial institution and whether another regulator already has authority over it, both worth confirming with counsel. Where it applies, it requires a Qualified Individual, a risk assessment, encryption, multi-factor authentication, training, vendor oversight and a written incident response plan, with some relief under 5,000 consumers. Separately, a covered customer’s rule, or a bank’s or credit union’s own regulator, reaches you through the contract and the questionnaire.
• Insurtech that is not licensed under Ohio insurance law, and does not need to be, is not the licensee; the customer is. But when an event happens in a system you maintain, the licensee has to investigate itself or confirm and document that you did, in the same week it is meeting its own notice duties.

Either way, the artifact is the same: a control that was configured, and a record showing it was configured on the day someone asked. Neither SOC 2 nor ISO 27001 is a law. Both are there because a buyer asked, and the report or certificate comes from an independent firm, not from us.

Who decides something is an incident, and who reports it?

An incident starts on an ordinary Tuesday: something in a log looks wrong, and somebody has to decide in the moment whether it is nothing or the start of a real incident. At most companies this page is written for, that is whoever happens to be looking, whenever they happen to be looking. That is a capability gap, not a paperwork gap.

Two things have to exist first. One is the logging a security review already asks about, kept somewhere that outlives the account that produced it. The other is a named person with the authority to make the call and run what follows, which is different from a policy naming a role.

Incident response ownership is one of the responsibilities our Virtual CISO engagements take on directly. Once something is confirmed, a buyer’s diligence and a cyber insurance policy both ask who reports it, on what timeline and to whom. Reporting to insurers or a board is part of the same scope.