# Fractional CTO vs vCISO for SOC 2 AI changes

> Fractional CTO vs vCISO responsibilities for SOC 2 AI change control, with a practical split for CC8.1 delivery, security review, and evidence.

A SOC 2 company should usually hire a fractional CTO to rebuild AI change delivery and a vCISO to set security requirements and challenge the resulting control. Asking either one to own both jobs creates a weak engagement: the builder reviews the builder, or the reviewer writes policies that engineering cannot execute.

CC8.1 does not settle the hiring decision. It tells the company to authorize, design, develop or acquire, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures. That chain crosses product delivery and security oversight. The right hire depends on which links are broken, and many AI adoption projects break links on both sides.

I have seen founders buy a polished AI policy while developers paste customer data into unapproved tools. I have also seen engineering teams add excellent automated checks without defining who may accept the residual risk. Both companies can produce screenshots. Neither has dependable change control.

## CC8.1 assigns work, not a job title

The AICPA Trust Services Criteria puts responsibility on the entity, so an auditor will test the control the company describes rather than look for a particular executive title. A fractional CTO and a vCISO are staffing choices. They are not controls, certifications, or substitutes for management accountability.

The wording of CC8.1 matters because it covers more than source code. Infrastructure, data, software, and procedures all sit inside the criterion. An engineer enabling an AI code-review bot changes software delivery. A support leader sending tickets to a summarization model changes a data flow and often a procedure. A team allowing an agent to modify cloud configuration changes infrastructure. Treating only production deployments as changes leaves obvious gaps.

The criterion also names distinct actions. Authorization asks whether the company has decided that a class of change may begin. Design and development turn that decision into a technical change. Configuration matters when the company acquires an AI service rather than builds one. Documentation records intent and impact. Testing produces evidence about behavior. Approval accepts the tested change. Implementation puts it into use.

Small companies often collapse those actions into one pull-request approval. That can work for a low-risk code change if the approval is meaningful and the automated evidence is attached. It works poorly for a new AI tool that can read repositories, production logs, customer conversations, or secrets. The decision to permit that data access belongs before the first developer connects the tool, not inside a pull request after credentials already exist.

Start the staffing decision by marking which CC8.1 verbs fail in practice. If changes lack an owner, architecture, test path, rollback method, or reliable deployment evidence, the delivery system needs executive engineering work. If the company cannot classify AI data use, set approval thresholds, assess vendors, define prohibited uses, or test whether security policy operates, it needs security leadership. If both columns are weak, hiring one generalist and renaming the gaps will not fix them.

SOC 2 also does not certify a product or declare every company decision secure. A SOC 2 examination reports on a defined system, period, criteria, and the controls in the service organization's description. Founders should ask their CPA how a proposed control and system-boundary change affects the examination. A fractional executive can prepare the company, but cannot promise the auditor's conclusion.

## The fractional CTO owns the delivery mechanism

A fractional CTO should own the way an approved AI change moves from an idea to a controlled production state. That means turning policy into architecture, repository rules, test gates, deployment paths, rollback procedures, and evidence that engineers produce while doing normal work.

This is not clerical ticket administration. AI changes cut across build systems, identity, data access, model configuration, prompts, evaluation sets, observability, and vendor APIs. The CTO must decide where each artifact lives and how the pieces fail safely. A policy that says "test AI output" is useless until someone defines the test corpus, acceptable results, failure threshold, reviewer, and release consequence.

The fractional CTO's scope should include an inventory of AI-enabled workflows that touch the system description. For each workflow, the CTO maps the data source, model or service, identity used, permissions, generated output, human review point, destination, logging, and disable path. This inventory is technical enough to expose shadow connections that a questionnaire misses.

The CTO then fits change classes into the existing software lifecycle. A model-version update in a customer-facing feature may require offline evaluation, security tests, product acceptance, a staged rollout, and a rollback trigger. A developer assistant with read-only access to a test repository may need vendor approval, access provisioning, and periodic review but no production release. A coding agent allowed to merge infrastructure changes needs far tighter branch protection and execution isolation.

The engagement should leave working controls, not a diagram that expires when the consultant leaves. Typical deliverables include:

- a change taxonomy with risk tiers and required evidence;
- repository and CI rules that enforce review and tests;
- an AI evaluation runner tied to release decisions;
- deployment and rollback procedures for model, prompt, and permission changes;
- evidence retention that matches the company's audit process.

The CTO can also train engineers and inspect samples until the workflow becomes routine. That is delivery ownership. The CTO should report exceptions and unresolved risks to management and the vCISO, but should not quietly approve deviations from security policy on the company's behalf.

Scope the outcome in observable terms. "Advise on AI transformation" is too vague. "Map all in-scope AI data flows, implement three risk-based change paths, enforce the selected gates in CI, and produce an evidence package for sampled changes" gives both sides something to accept. Name systems and repositories in the statement of work. Name exclusions too, especially employee-only AI tools, experimental sandboxes, acquired services, and business procedures that engineering does not own.

## The vCISO owns security requirements and challenge

A vCISO should own the security rulebook for AI use and independently test whether the delivery mechanism follows it. The role sets risk criteria, defines prohibited and conditional uses, leads security review of vendors and data flows, specifies exception handling, and reports control performance to management.

"Independently" needs a practical definition in a small company. It does not require a separate department. It requires a person who did not implement the sampled change to review whether the control design and evidence meet the approved security requirement. The same fractional professional can advise engineering in one meeting and perform oversight in another only if the company identifies the conflict, assigns alternate approval where needed, and keeps the two decisions visible. Separate people are cleaner when a high-risk AI feature affects customers or regulated data.

NIST's AI Risk Management Framework makes this separation explicit without prescribing these job titles. GOVERN 2.1 calls for documented roles, responsibilities, and communication lines for mapping, measuring, and managing AI risk. GOVERN 2.3 assigns responsibility for deployment risk decisions to executive leadership. I agree with that split: the vCISO frames and challenges security risk, but the founder or authorized executive accepts business risk.

The vCISO's policy work should answer questions engineers can act on:

- Which data classes may go to an external model, and under what contract and configuration?
- Which AI actions always require human approval?
- What permissions may an agent hold in development and production?
- Which changes require threat modeling, privacy review, or an incident-response update?
- Who can grant an exception, for how long, and with what compensating control?

The vCISO should test samples across the full population, not only the tidy examples selected for an audit folder. That means comparing tool inventory to identity-provider logs, checking whether emergency changes received later review, examining rejected AI evaluations, and tracing one deployed version back to authorization. The goal is to find where the process lies.

Do not ask the vCISO to become the release manager for every AI pull request. That creates a security queue, encourages rubber-stamp approvals, and makes the reviewer part of routine implementation. Security should define which risk conditions trigger its approval. Engineering can handle ordinary changes inside those boundaries and escalate the exceptions.

A useful vCISO engagement ends with control criteria, review records, exception decisions, findings, and management reporting. It should not end with a generic "responsible AI" policy copied from a large enterprise. A ten-person company needs fewer rules, sharper triggers, and named decision-makers.

## Hire for the missing decision, then add the second role

Hire the fractional CTO first when management has approved AI use but engineering cannot implement repeatable, evidenced changes. Hire the vCISO first when teams are already using AI and nobody can state what data, permissions, vendors, or use cases the company permits. Hire both when customer-facing AI or privileged agents are moving into production while the security governance is still being written.

The cheapest wrong answer is to choose by title familiarity. Founders often know they need "security" for SOC 2, so they give all AI change control to a vCISO. The vCISO produces policy, risk registers, and review forms, but nobody changes the pipeline. Engineers keep screenshots by hand until the evidence burden collapses. The policy owner gets blamed for an engineering system the engagement never funded.

The opposite error comes from assuming the CTO already owns every technical risk. The CTO moves fast, adds evaluations and approval gates, and makes sensible architecture choices. Yet that same person defines the acceptable risk, builds the mechanism, approves exceptions, and reports that it works. A competent builder can still miss the assumptions embedded in the design.

Use this allocation when scoping the first engagement:

- With no AI policy, unknown tools, and unclear data rules, start with the vCISO alongside the founder and engineering lead.
- With approved rules but manual releases, weak tests, and weak evidence, start with the fractional CTO alongside the security policy owner.
- For AI entering production and interacting with customers, use both roles and keep the founder as risk owner.
- For privileged coding agents that change infrastructure, use both roles alongside the system owner and security reviewer.
- For a narrow internal pilot using public or synthetic data, start with the fractional CTO and name a security reviewer who may work part time.

The "first owner" does not own the company decision forever. It identifies the immediate bottleneck. A vCISO who discovers an unenforced policy should open a delivery workstream. A fractional CTO who discovers undefined data-risk rules should stop guessing and request a security decision.

Company size changes the staffing pattern, not the responsibilities. One employee may wear several hats, and a fractional leader may cover a temporary vacancy. Record which hat the person wore for each decision. When segregation is impossible, use a compensating review by the founder, another technical leader, or an outside specialist who has enough context to challenge the change.

## A RACI must follow the change record

The useful RACI is attached to actual decisions, so each change shows who proposed, implemented, reviewed, approved, and monitored it. A slide with "CTO: responsible, CISO: accountable" is too broad to test and too vague to run.

For a material AI change, I use a simple starting allocation. The founder answers for the business objective, risk tolerance, and any security exception beyond delegated limits. The vCISO performs and answers for security and data classification, then reviews how the control operates. The fractional CTO answers for architecture, implementation, and tests while engineers perform the detailed work. The CTO performs the production authorization process under authority delegated by management, consulting the vCISO when a security trigger fires.

In conventional RACI notation, R means the person performs the work. A means the person answers for the decision. C means the person supplies input, and I means the person receives the result. The allocation is a starting point because the system owner, data sensitivity, and blast radius may justify different assignments.

Notice that production authorization and security approval are separate. A vCISO can say that a change meets the security conditions while the product owner rejects it for accuracy or operational reasons. A founder can accept a documented security exception but still require the CTO to implement a compensating restriction before release.

Put names or role identifiers in the change system, not only in policy. If "vCISO" approves a risk but the company cannot show which person held that role on the date, the record loses force. Effective dates matter when fractional leaders rotate.

Define delegation. The fractional CTO should not personally approve every routine dependency update. The control can delegate low-risk release authorization to an engineering lead when tests pass and no trigger fires. The vCISO should specify triggers such as new sensitive data, expanded agent permissions, a new external model provider, disabled logging, or an evaluation below threshold.

The founder remains accountable for staffing and risk acceptance. Outsourcing the work does not outsource the entity's control responsibility. Put that sentence into both statements of work before a difficult exception tests it.

## Evidence should fall out of delivery

Good CC8.1 evidence is the durable record of a real decision, not a screenshot assembled because an auditor asked. AI change records need a little more context than ordinary application changes because model behavior, prompts, data access, and permissions can change independently of source code.

Use one compact record per material change. This example is intentionally plain YAML so a team can keep it beside code or generate the same fields in a ticket:

```yaml
change_id: AI-2026-041
owner: payments-platform
business_objective: reduce manual ticket classification
change_class: customer-data-ai
systems_affected: [support-api, model-gateway]
data_classes: [customer-confidential]
provider_or_model: approved-provider/model-version
permissions_added: [read:support-ticket]
tests:
  functional: ci://run/18442
  security: ci://run/18443
  ai_evaluation: eval://run/771
approval_triggers: [external-model, customer-confidential]
security_review: SEC-882
release_approver: person-id-17
rollback: disable feature flag ai_ticket_classification
deployed_artifact: image-digest-placeholder
deployed_at: 2026-04-18T16:20:00Z
```

The identifiers do not need public URLs. They need to resolve inside the company's evidence boundary and remain readable for the retention period. Replace placeholders with immutable run IDs, artifact digests, ticket IDs, and identities that the company can retrieve.

The fractional CTO should make the pipeline populate objective fields such as commit, test run, artifact digest, deployment time, and environment. Humans should supply judgment fields such as business objective, data classification, exception rationale, and approval. Asking people to copy machine facts into a form creates transcription errors without adding control.

A simple sampling command can expose whether deployed commits have review records:

```bash
git log release-2026-04..release-2026-05
```

Its default output repeats a block for each commit with the commit hash, author, date, and message. Join that population to pull requests, CI runs, approvals, and deployment records. Do not select five clean tickets first and call them the population.

The vCISO tests whether the required triggers produced reviews and whether exceptions expired. The CTO fixes missing joins, unstable identities, or bypassable gates. The founder receives a short control report: population size, samples or automated coverage, exceptions, failed checks, overdue remediation, and accepted risk.

NIST SP 800-218 describes the Secure Software Development Framework as outcome based and meant to fit an organization's risk tolerance and resources, not as a fixed checklist. That is the right approach here. Automate evidence where automation proves the outcome, and keep human judgment where a machine cannot accept responsibility.

## An AI agent exposes weak boundaries fast

A privileged coding agent can pass every ordinary test and still reveal that the company never separated authorization, implementation, and approval. Walk through a common failure.

Management approves a coding assistant for an isolated repository. An engineer later connects it to the main repository because the pilot went well. The token can read code, open pull requests, and call a deployment tool. The engineer updates a configuration file so the agent can fix routine issues. Nobody records the expanded permissions as a new change because the software vendor and agent name stayed the same.

The agent opens an infrastructure change after diagnosing a production alert. Unit tests pass. A developer reviews the diff but does not know that the agent used production log content in its prompt or that its token can trigger deployment. The normal merge gate records one approval, and the deployment succeeds.

The evidence folder looks respectable: ticket, pull request, passing CI, reviewer, and deployment log. The missing control decisions sit outside that chain. Nobody authorized the new data flow. Nobody classified the permission expansion. The security review trigger did not fire. The test plan covered code behavior but not prompt disclosure, tool scope, or rollback of the agent credential.

The fractional CTO fixes the delivery path by putting agent identities in the asset inventory, separating read and write credentials, restricting deployment calls, detecting permission-file changes, and connecting evaluation and security-review IDs to releases. The vCISO defines which log fields the agent may process, what agent permissions require review, which providers are approved, and how long an emergency exception can live.

Many teams respond by requiring the vCISO to approve every agent action. That recommendation sounds safe because it adds a human. It is wrong for routine work. The approval queue grows, reviewers stop examining context, and engineering finds another path. Approve the capability and boundaries at the right risk level, then make the system block actions outside them.

Emergency work needs its own path, not an undocumented bypass. Permit a limited break-glass identity, capture who activated it and why, constrain its duration, log every action, and require later review by someone outside the implementation. If emergencies become frequent, the exception path has replaced the control and management should treat that as a finding.

## Two statements of work prevent one blurred role

Write separate outcomes, authority limits, and acceptance criteria for the fractional CTO and vCISO even if one firm supplies both people. The contract should make the control boundary clearer than the sales proposal did.

The fractional CTO statement of work should name the delivery systems, AI workflows, repositories, environments, and control automation in scope. It should require implemented gates, tested rollback, technical inventory, evidence joins, engineering training, and remediation of agreed gaps. It should state who owns the systems after the engagement and what maintenance remains.

The vCISO statement of work should name the policies, data classes, vendor risk decisions, security-review triggers, exception process, control tests, and management reports in scope. It should describe access to logs and staff, reporting independence, escalation, and the cadence for testing. It should not make the vCISO accountable for product delivery schedules.

Both contracts need explicit exclusions. Ask whether the engagement covers employee use of public AI chat tools, local models, customer-facing features, coding assistants, autonomous agents, model training, support automation, and acquired SaaS features that quietly add AI. "AI systems" without this list invites a scope dispute.

Avoid success measures that reward paperwork volume. Count change paths enforced, systems inventoried, triggered reviews completed, exceptions aged, evidence joins that resolve, and corrective actions closed. A policy page count tells management nothing about operation.

Set an end condition. Fractional leadership can be month to month, but the control still needs a handoff standard: named internal owners, accessible runbooks, maintained automation, open-risk register, and a calendar for review. Otherwise the company rents institutional memory and loses it on termination.

At oleg.is, I use a Team & AI Audit to identify where delivery and oversight are mixed before proposing a fractional CTO engagement. The audit is a scoping mechanism, not a SOC 2 opinion, and the company's CPA remains the right person to confirm how control changes affect its examination.

## The first 30 days should produce operating proof

The first month should produce a bounded AI inventory, one agreed responsibility model, and evidence from at least one real change path. Do not spend 30 days perfecting a policy while AI access continues to spread.

In the first week, management names the in-scope system, risk owner, technical owner, security reviewer, and auditor contact. The team inventories active AI use through interviews plus available identity, expense, browser-management, repository, and network records. It labels unknowns instead of pretending the list is complete.

During the second week, the vCISO proposes data and permission rules, review triggers, and an exception path. The fractional CTO tests those rules against actual workflows and points out conditions the systems cannot observe or enforce. Management resolves conflicts and signs the risk decisions.

During the third week, engineering implements one high-frequency change path. Pick a path that can prove the pattern, such as a coding assistant configuration change or a model update behind a feature flag. Connect authorization, tests, triggered security review, release approval, deployment identity, and rollback evidence.

During the fourth week, the vCISO samples the path and tries to break it. Can an engineer use an unapproved provider? Can a service identity widen its own permissions? Can someone merge with a stale evaluation, reuse an old approval, or deploy an artifact different from the tested one? The CTO repairs the mechanism, and management records any risk it chooses to accept.

Bring the result to the CPA early, especially if the system description, control wording, evidence source, or responsible role changes. Auditors need enough independence to examine the control, so do not ask them to design it for you. Ask whether the description is understandable, whether the evidence supports the stated operation, and whether the change affects the planned examination.

After 30 days, the company should be able to select a deployed AI-related change and reconstruct its objective, data use, permission impact, tests, approvals, artifact, deployment, and rollback. If it cannot, it still has a change-control project. If one person created every artifact and approved every decision, it also has an oversight project. Those are two scopes, even when the org chart has room for only one fractional executive at a time.