IT SOPs are the documented procedures for every significant IT operation — incident response, change management, access control, backup and recovery. ISO 27001, SOC 2, PCI-DSS, and CMMI all require them. Without them, every IT incident becomes improvised, and every security audit finds the same gap.
ISO 27001 cl. 7.5
Documented information control
SOC 2
Controls must be documented and followed
Version-controlled
Undated IT SOPs are not credible evidence
An IT SOP is the written procedure your team follows for a specific IT operation. Incident response, deployment procedures, backup verification, user access provisioning — all should have documented steps. Following the SOP consistently is what makes your team's work auditable and reproducible.
Follow
The SOP — not your memory of it
Current
Check version before following old procedures
Report
Any SOP that doesn't match reality — flag it
Quick reference. IT SOPs required by: ISO 27001 cl. 7.5 (documented information), SOC 2 (controls must be documented, evidence of operation required), PCI-DSS requirement 12.5 (security policy and procedures), CMMI-DEV (defined processes). Key IT SOPs: incident response, change management, access provisioning and de-provisioning, backup and recovery, vulnerability management, business continuity.
ISO 27001 cl. 7.5
Documented information
SOC 2 CC6
Control documentation requirement
PCI-DSS Req. 12
Security policy and procedures
IT SOPs are the application of standard operating procedure principles to IT operations. They define who does what, in what sequence, with what authority, when a specific IT event or operation occurs. In ITSM frameworks like ITIL, IT SOPs are the documented work instructions that sit below process definitions.
Reproducible
Same outcome regardless of who follows the SOP
Auditable
Evidence that the right steps were followed
Improvable
SOPs can be updated when better approaches are found
Required by ISO 27001 cl. 7.5, SOC 2, PCI-DSS, and most IT compliance frameworksIncident procedures must be known before the incident — training is not optionalVersion control and change tracking required — an undated IT SOP is an untrustworthy IT SOP
What’s on this page
01 —What it isUnderstanding IT SOPs
The documented procedures your IT team follows — and the evidence your auditors ask for.
IT SOPs are the written, version-controlled procedures for IT operations. Incident response, change management, access provisioning, backup verification, deployment checklists — each should have a documented procedure that any trained team member can follow and produce a consistent, predictable result.
Every major IT compliance framework requires documented IT procedures: ISO 27001 clause 7.5 requires documented information for IT operations. SOC 2 requires controls to be documented and evidence of their operation. PCI-DSS requirement 12.5 requires written information security policies and procedures. CMMI Level 3 requires defined processes with documented work instructions.
The most common IT audit finding: IT procedures exist informally in senior engineers' knowledge — not written down, not trained out, not followed consistently. When two engineers handle the same type of incident differently, the result is unpredictable outcomes and non-compliance.
Incident procedures must be known before the incident occurs. Writing an incident response SOP after the incident is like installing fire exits after the fire. The procedure must be written, reviewed, trained, and practiced before the event it covers.
👥 Illustrative case — details changed for confidentiality
The business
FinTech company Bangalore · 160 employees, processing payment transactions
The trigger
A PCI-DSS assessment and a concurrent ISO 27001 pre-audit both identified the same gap: IT procedures existed informally in engineers' heads but were not documented, version-controlled, or trained out.
The challenge
When a production incident occurred at 2 AM, three different engineers followed three different escalation paths. The incident took 4 hours to resolve — longer than it should have because there was no documented procedure.
Where Clicarity came in
They built their IT SOPs as tracked jobs in Clicarity. The incident management procedure was split into two sub-jobs: the technical classification and escalation procedure (owned by the on-call engineer), and the stakeholder communication procedure (owned by the operations lead). Both required security review and training before going live.
The result
PCI-DSS gap closed. ISO 27001 clause 7.5 (documented information) finding resolved. Next 2 AM incident resolved in 47 minutes.
The procedure existed in everyone's head but differently. Writing it down unified the response.
02 —Who needs itIs it right for you?
Do you actually need it? Honest answer.
✓ You need IT SOPs
IT companies and SaaS companies pursuing ISO 27001, SOC 2, or PCI-DSS
Software companies pursuing CMMI Level 3
IT departments of organisations with significant IT operations
Managed service providers with multiple clients
∼ Useful even without formal compliance
Growing IT teams where multiple people now share the same operations responsibilities
After any significant IT incident — the post-incident review output
— Not a priority yet
Single-engineer IT setups — knowledge is by definition with one person
03 —What it requiresWhat is checked
The core IT SOPs every technology team needs.
1
Incident response procedure
Step-by-step procedure for identifying, classifying, escalating, resolving, and closing IT incidents. Includes severity classification matrix and escalation contacts.
E.g. P1 (complete outage): engineer assesses within 15 minutes, escalates to IT lead within 30 minutes, management notification within 1 hour, resolution target 4 hours.Most common gap: Procedure exists but escalation contacts are outdated or the engineer on call hasn't been trained on it.
2
Change management procedure
Process for requesting, reviewing, approving, implementing, and verifying IT changes. Prevents unauthorised changes causing incidents.
E.g. Change request form: description, impact assessment, rollback plan, approval required. Emergency changes: verbal approval then retrospective documentation.
3
Access provisioning and de-provisioning
How IT access is granted, modified, and revoked. Role-based access. Joiner, mover, leaver process.
E.g. New employee joins: HR triggers access request. IT provisions based on approved role. Employee moves: access reviewed and adjusted. Employee leaves: access revoked within 24 hours.
4
Backup and recovery procedure
How data backups are performed, where stored, how frequently tested, and how recovery is performed in a disaster.
E.g. Daily backup of production database. Weekly backup test — restoration to test environment. Annual DR drill. Results documented.Most common gap: Backups running but never tested. Backup restoration fails in a real disaster.
5
Vulnerability management procedure
How IT systems are scanned for vulnerabilities, how findings are prioritised, and how patches are applied.
E.g. Monthly vulnerability scan. Critical findings patched within 30 days. High findings within 60 days. Results tracked.
6
Business continuity and disaster recovery procedure
What happens when a major system or site failure occurs. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined and tested.
E.g. RTO 4 hours (systems restored within 4 hours of disaster). RPO 1 hour (maximum 1 hour of data loss). Annual DR test documented.
What inspectors really check
ISO 27001 auditors ask: "Show me your incident response procedure and show me the last 3 incidents handled using it." SOC 2 auditors sample change management tickets from across the 12-month period. PCI-DSS assessors verify access de-provisioning records for employees who left during the year.
Gap analysis checklist — tick what you already have
Incident response procedure documented and trained
Staff know the procedure before an incident occurs.
Change management procedure — all production changes logged
No undocumented changes to production systems.
Access provisioning and de-provisioning procedure
Leaver access revoked within 24 hours, evidenced.
Backup procedure with tested recovery
Restoration tested — not just backup running.
Vulnerability management with patching timelines
Tracked by severity.
Business continuity plan with defined RTO and RPO
DR drill conducted and documented annually.
All IT SOPs version-controlled with review dates
No undated IT SOPs in use.
0 of 7 complete
04 —Official bodyWho certifies in India
Who issues this in India — and how to verify it.
IT SOPs are internal documents. Their adequacy is assessed by external auditors (ISO 27001 CBs, SOC 2 CPA firms, PCI-DSS QSAs) during compliance assessments.
Version control is not optional for IT SOPs. An undated, unversioned IT SOP cannot demonstrate currency. When the auditor asks "is this the current version?" you must be able to answer definitively. Use a simple version number and effective date on every IT SOP.
Check alignment with ISO 27001, SOC 2, or PCI-DSS as applicable.
Step 4
Test run each SOP
Follow it on a real event. Find and fix gaps.
Step 5
Train all IT staff
Acknowledgements signed.
Ongoing
Version control and annual review
Plus triggered review after any significant IT change.
▶Where to begin: Use the checklist in Section 3 to assess your readiness before contacting any CB.
Format
One SOP per process
Incident SOP, change SOP — separate documents.
Version control
Version number + effective date
On every IT SOP — mandatory.
Review trigger
After any significant system change
Plus annual review.
Training
Before the SOP is needed
Not during the incident.
The backup procedure is the most dangerous gap. Most IT teams run backups — but have never tested recovery. When the disaster happens, they discover the backup is corrupt or the recovery procedure doesn't work. Test the restoration. Document the result.
06 —Find certified companiesHow to verify
How to find and verify certified organisations.
IT SOPs are internal documents. Compliance with IT SOP requirements is indirectly evidenced through ISO 27001 certification, SOC 2 reports, or PCI-DSS compliance certificates.
How to verify: To confirm whether any organisation holds a current IT SOPs certification, use the official register. Verify the issuing CB's accreditation at nabcb.qci.org.in.
Write your incident response procedure this week — based on the last incident you handled
The best IT SOPs are written from real incidents. Take your last significant IT incident and document exactly what should have happened.
2
Test your backup restoration — today, not when a disaster occurs
Schedule a backup restoration test this week. Document the result. If it fails, fix it.
3
Version-control every IT SOP you already have — add version number and effective date
Take every existing IT document and add a version number and effective date. This makes existing work immediately auditable.
08 —How Clicarity fitsProcess tracking
Good records are the foundation. A process tracker builds them automatically.
Clicarity — Live Job Process Tracker & Bottleneck Identifier
Clicarity doesn't manage your IT systems. It tracks the IT SOP creation and approval process — ensuring every procedure has a security review, a training record, and a version trail.
IT SOPs fail for the same reason production SOPs fail: written informally, not version-controlled, and the team finds out the SOP is wrong only when an incident occurs. In Clicarity, each IT SOP is created as a job with stages: draft, technical review, security and compliance review, test run, approval, training, and publication. When a procedure has technical and communication components (as most incident procedures do), each component runs as a separate sub-job with its own owner. The SOP goes live only after all stages are complete — not when the engineer finishes writing it.
Security and compliance review stage required before publication — every IT SOP checked for ISO 27001, SOC 2, or PCI-DSS alignment before it goes live.
When a procedure has technical and communication components, each runs as a sub-job with its own technical owner and training audience.
Training stage: staff trained and acknowledgements signed before the SOP becomes effective — the incident procedure must be known before the incident occurs.
Clicarity shows which IT SOPs are overdue for review — when a procedure hasn't been reviewed after a significant system change, it's visible before the next incident or audit.
📄 Job tracked in Clicarity
#ITSOP-2026-01 — IT SOP creation — Incident management procedure
SOP initiated
✎SOP title
✎IT process covered
▼Author — IT/DevOps
▼IT manager sponsor
📅Draft due date
→
Draft written
✎SOP ref. no.
▼Version
▼Draft author
📅Draft date
📷Draft document
→
Technical review
▼IT lead reviewed
▼Security team reviewed
▼Legal / compliance reviewed
✎Changes made
📅Review date
→
Test run
#Test incidents handled
▼Test outcome
✎Issues found
▼Adjustments made
📅Test date
▼ Job splits — each component tracked independently
#ITSOP-2026-01-A
Incident classification & escalation procedure
▼Technical lead approval
▼Training completed
#Staff trained
#ITSOP-2026-01-B
Communication & stakeholder notification procedure
▼Comms lead approval
▼Training completed
#Staff trained
▲
Components rejoin as #ITSOP-2026-01 — complete record of every branch, every data point, every sign-off preserved.
Security & compliance review
▼CISO / IT security reviewed
▼ISO 27001 / SOC 2 alignment checked
▼Legal confirmed
📅Date
→
Approval & publish
▼IT director approved
📅Effective date
✎SOP no. on master list
▼Previous version archived
→
Training rollout
#Staff trained
▼Trainer
📅Training date
▼Acknowledgements signed
Wastage tracked:▰ Incident classification and stakeholder communication are separate sub-procedures — different owners, different stakeholders▰ Security compliance review required before publication — not optional▰ Training completed before the SOP goes live — staff must know the procedure before an incident occurs
ⓘ Fields and stage names are fully customisable. This illustrates a typical IT team — IT SOP creation and approval process setup.
👥 Illustrative case — details changed for confidentiality
The business
FinTech company Bangalore · 160 employees, processing payment transactions
The trigger
A PCI-DSS assessment and a concurrent ISO 27001 pre-audit both identified the same gap: IT procedures existed informally in engineers' heads but were not documented, version-controlled, or trained out.
The challenge
When a production incident occurred at 2 AM, three different engineers followed three different escalation paths. The incident took 4 hours to resolve — longer than it should have because there was no documented procedure.
Where Clicarity came in
They built their IT SOPs as tracked jobs in Clicarity. The incident management procedure was split into two sub-jobs: the technical classification and escalation procedure (owned by the on-call engineer), and the stakeholder communication procedure (owned by the operations lead). Both required security review and training before going live.
The result
PCI-DSS gap closed. ISO 27001 clause 7.5 (documented information) finding resolved. Next 2 AM incident resolved in 47 minutes.
The procedure existed in everyone's head but differently. Writing it down unified the response.
Clicarity is a process tracking tool. It does not provide certification, consulting, or audit services.