SOC 2 for a small managed IT provider: controls across the service

A small managed IT provider can have a sensible SOC 2 program without building a large compliance department. The work needs to cover the service you actually deliver. That includes your technicians, your management tools and the boundaries between customer environments.

The aim is not a folder full of policies. It is a service that runs as promised, with records showing what happened when someone checked or changed it. Here is a practical starting model for a provider offering remote support and ongoing IT management.

Decide what the report will cover

Start with a short description of the service. Name the customer environments you manage and the tools your technicians use. Include the systems that hold customer credentials or can issue commands across several customers.

• Identify the services included, such as endpoint management or help-desk support.
• Separate purchased services from assumptions. Backup monitoring is not the same service as proving recovery.
• List important dependencies, including remote-management software and any outsourced monitoring team.
• Record customer responsibilities and exclusions. Make these understandable to the customer.

SOC 2 addresses controls relevant to the selected Trust Services categories. SOC 1 addresses controls relevant to customers’ financial reporting. They are not interchangeable. Discuss the report scope with the CPA firm rather than choosing a report just because another IT provider has one. See the AICPA’s SOC overview.

Give the program an owner

One person should coordinate the program. The technical lead still owns technical work. The service manager owns delivery commitments. The business owner resolves risks that require money or a change in the service.

Keep a short list of the most important risks. For this business, a technician account that reaches every customer deserves particular attention. So does a management-platform failure that stops the whole team working.

For each priority, name the control owner and the record you expect to see. Review overdue work and repeated failures together. A small team can use its existing ticket system instead of buying a separate platform.

1. Protect technician access

Technicians need enough access to do the job. They do not all need permanent administrator access to every customer.

• Use individual identities where supported. Protect powerful accounts with strong authentication.
• Separate ordinary work from administrative work where practical. Protect technician devices as part of the service.
• Grant access for the assigned role and customer work. Remove it when assignments or employment end.
• Check access periodically and after important role changes. Include contractors and emergency accounts.

Evidence to keep: Approved access requests, removal results and the access review with any corrections. A list of accounts alone does not show someone checked whether access was appropriate.

Where a legacy customer system forces shared access, record the limitation. Restrict who can retrieve the credential and how use is traced. Agree a safer path with the customer rather than describing shared access as if it were an individual login.

2. Keep customer boundaries clear

A multi-customer console makes support efficient. It also creates opportunities to select the wrong customer or expose the wrong records.

• Restrict technician access to the customer groups they need.
• Check customer identity before changing access or disclosing sensitive information.
• Keep credentials in an approved vault rather than ticket notes.
• Test customer separation when configuring a new shared tool or changing its permission model.

Evidence to keep: The approved permission design and test results. Keep records of mistakes and how you corrected them. Do not place live passwords in the audit evidence folder.

3. Control changes and routine maintenance

A script that works on one device may fail across a customer fleet. Treat broad deployment as a service change, not just another technician task.

• Identify the affected customers and obtain approval where required.
• Test changes proportionately. Plan how to stop or reverse a failed rollout.
• Track patch coverage and failures. Assign unresolved devices instead of treating a launched job as complete.
• Use a defined emergency route. Review urgent changes afterward and resolve anything left unfinished.

Evidence to keep: The change ticket, test or review result and deployment outcome. For maintenance, retain coverage and exception records. A green dashboard is useful only if it includes the systems you promised to manage.

4. Make monitoring lead to action

Define who receives alerts and when someone is expected to act. Do not sell continuous response when the service only sends notifications after hours.

• Identify the events that matter for the service and ensure someone reviews them.
• Set escalation contacts and backup coverage.
• Explain when technicians may isolate a device or disable access without waiting.
• Practice a scenario involving a compromised management account. Include customer communication and evidence preservation.

Evidence to keep: Alert handling records, escalation decisions and exercise findings. Follow up on missed alerts or unreachable contacts. An exercise is useful when it changes something that would otherwise fail.

5. Plan recovery for your service and theirs

There are two different questions: can you restore a customer’s agreed systems, and can your own team keep delivering service? Losing access to your ticket system or credential vault can stop support even when customer servers are healthy.

• Define recovery coverage and objectives for the services you provide.
• Test useful recovery, not just whether the backup job completed.
• Document how staff contact customers when normal tools are unavailable.
• Check important providers and make a plan for a prolonged outage or exit.

Evidence to keep: Recovery test results with the actual outcome and unresolved gaps. Retain the provider review and any decision to accept a limitation. Do not claim customer recovery coverage for systems outside the contract.

6. Handle customer information throughout its life

Support tickets may hold screenshots, logs or exported files. Decide what staff should collect and where it can go. Avoid collecting customer data simply because it might help later.

• Limit access to support records and exports.
• Define retention and disposal rules that fit contracts and applicable obligations.
• Review third parties that receive customer information.
• At contract end, remove access and arrange the agreed return or deletion of information.

Evidence to keep: Provider decisions, relevant configuration checks and customer exit records. If a record must be retained, explain why and keep it protected.

Keep the evidence simple

For each control, write down the task, owner and timing. Then identify the existing record that proves it happened. Add the result and follow-up when something fails. You usually do not need a new tracker for every task.

For example: the service manager reviews privileged access against current assignments. The retained record identifies the accounts reviewed and the changes made. The review frequency should reflect your risks and commitments, not a timetable copied without thought.

These are implementation examples, not a complete list of mandatory SOC 2 controls. The AICPA Trust Services Criteria cover the wider control environment as well as technical safeguards. Your program also needs appropriate staff competence, risk assessment and oversight. Selected categories and service commitments affect the detailed design.

Start with a service walkthrough

Pick one customer and follow the service from onboarding through ordinary support to eventual exit. Check who approves work, what systems are involved and where evidence is produced. Then check whether that process holds across the rest of your customer base.

Resolve the largest gaps before making ambitious claims about readiness. A Type 2 examination tests operating effectiveness over a period. A policy written just before the audit does not establish that the process operated throughout that period.

The Canadian Centre for Cyber Security’s managed-services guidance is useful for understanding the questions customers should ask about access, incidents and recovery. For the other side of these responsibilities, see what a small business still needs to do when it outsources IT.

A useful first milestone is straightforward: everyone knows what the service includes, who does the work and where to find evidence that it was done.