1. Purpose
The IT Operations Procedure defines how the organization’s IT systems, infrastructure, applications, networks, cloud environments, endpoints, accounts, backups, logs, and operational services are securely managed and maintained.
The objective is to ensure that IT operations are:
- Secure
- Reliable
- Controlled
- Available
- Monitored
- Documented
- Recoverable
- Consistent
- Audit-ready
Core Principle
Plan → Operate → Monitor → Protect → Record → Review → Improve
2. Scope
This procedure applies to IT operations supporting the organization’s:
- Cloud infrastructure
- Servers
- Endpoints
- Network infrastructure
- Applications
- SaaS platforms
- Databases
- Storage
- Backup systems
- Identity and access management
- Security tools
- Monitoring systems
- Development and production environments
- IT service providers
- Managed services
- Third-party technology platforms
3. IT Operations Information
| Field | Details |
|---|---|
| Procedure ID | |
| Procedure Owner | |
| IT Operations Owner | |
| Security Owner | |
| Version | |
| Effective Date | |
| Review Date | |
| Classification | |
| Status | Draft / Approved / Retired |
| Related Policy | |
| Approved By |
4. IT Operations Objectives
IT operations should ensure:
☐ Systems are securely configured
☐ Systems remain available
☐ Changes are controlled
☐ Access is authorized
☐ Vulnerabilities are addressed
☐ Security events are monitored
☐ Backups are performed
☐ Recovery capability is maintained
☐ Incidents are handled
☐ Operational activities are recorded
☐ Critical dependencies are understood
☐ Evidence is available for review
5. IT Environment
Maintain an appropriate inventory of IT infrastructure.
| Asset/System | Environment | Owner | Criticality | Location | Status |
|---|---|---|---|---|---|
| Production | |||||
| Development | |||||
| Test |
Examples:
- AWS accounts
- EC2 instances
- RDS databases
- S3 buckets
- VPCs
- IAM
- GitHub
- CI/CD
- SaaS applications
- Employee laptops
- VPN
- Firewalls
- Monitoring platforms
6. IT Roles and Responsibilities
| Role | Responsibility |
|---|---|
| IT Operations Owner | Overall IT operations |
| System Owner | System-specific responsibility |
| Cloud Administrator | Cloud infrastructure |
| Security Team | Security controls and monitoring |
| Application Owner | Application operations |
| Database Owner | Database operations |
| Service Desk | User support |
| Vendor/Supplier | Outsourced IT services |
| Business Owner | Business requirements |
| Management | Oversight and escalation |
7. IT Asset Management
IT assets must be identified and appropriately managed.
☐ Hardware inventory maintained
☐ Software inventory maintained
☐ Cloud resources identified
☐ SaaS applications identified
☐ System owners assigned
☐ Criticality identified
☐ Asset status maintained
☐ Unauthorized assets investigated
☐ Assets securely disposed of
Asset Register
| Asset | Owner | Classification | Criticality | Lifecycle Status |
|---|---|---|---|---|
8. System Ownership
Each important system should have an identified owner.
The owner is responsible for:
- Business purpose
- Security requirements
- Access approval
- Configuration
- Operational health
- Risk management
- Change approval
- Incident escalation
- Periodic review
- Retirement
9. IT Environment Separation
Where appropriate, maintain separation between:
☐ Development
☐ Testing
☐ Staging
☐ Production
Production information should not be copied into lower environments unless appropriately authorized and protected.
Where production data is used for testing, consider:
- Data minimization
- Masking
- Anonymization
- Access restrictions
- Approval
- Retention
- Secure deletion
10. Standard IT Configuration
Systems should use approved configurations.
Configuration requirements may include:
- Secure operating-system configuration
- Approved software
- Security settings
- Authentication settings
- Network controls
- Logging
- Encryption
- Time synchronization
- Endpoint protection
- Backup configuration
Configuration Standard
11. Secure Configuration Management
For critical systems:
☐ Secure baseline defined
☐ Configuration documented
☐ Unauthorized changes monitored
☐ Administrative access restricted
☐ Security settings enabled
☐ Configuration reviewed periodically
☐ Configuration deviations recorded
12. User Access
Access to IT systems must be based on business need.
☐ Access request completed
☐ Appropriate approval obtained
☐ Individual account assigned
☐ Least privilege applied
☐ MFA enabled where required
☐ Privileged access restricted
☐ Access logged where appropriate
☐ Access periodically reviewed
☐ Access removed when no longer required
Access Principle
Need → Approve → Grant → Monitor → Review → Revoke
13. Privileged Access
Privileged access must be tightly controlled.
☐ Named administrator accounts
☐ MFA
☐ Least privilege
☐ Business justification
☐ Approval
☐ Logging
☐ Monitoring
☐ Periodic review
☐ Emergency access process
☐ Timely revocation
Shared administrator accounts should be avoided unless technically necessary and appropriately controlled.
14. Authentication and Credentials
IT operations must protect authentication information.
☐ Strong authentication
☐ MFA
☐ Password controls
☐ Secure credential storage
☐ Secrets management
☐ Credential rotation
☐ Access-key management
☐ Credential revocation
☐ No credentials stored in source code
Passwords, API keys, private keys, tokens, and other secrets must not be included in ordinary operational records.
15. Cloud Operations
Where cloud services are used:
☐ Cloud accounts identified
☐ Account ownership defined
☐ IAM controlled
☐ MFA enabled
☐ Root/admin access restricted
☐ Network controls implemented
☐ Encryption configured
☐ Logging enabled
☐ Monitoring enabled
☐ Backup configured
☐ Security configuration reviewed
☐ Cloud resources periodically reviewed
16. AWS Root Account
For AWS environments:
☐ Root account use restricted
☐ MFA enabled
☐ Root credentials securely protected
☐ Root access keys avoided
☐ Administrative activity performed through controlled IAM identities
☐ Root-account activity monitored where applicable
☐ Emergency access procedure defined
Root access should be reserved for activities that specifically require it.
17. Network Operations
Network infrastructure must be securely operated.
Consider:
☐ Firewalls
☐ Security groups
☐ Network segmentation
☐ VPN
☐ Secure remote access
☐ Network access restrictions
☐ Administrative access controls
☐ Network monitoring
☐ Intrusion detection/prevention where appropriate
☐ Network configuration backup
18. Endpoint Operations
Organizational endpoints should be appropriately protected.
☐ Approved devices
☐ Endpoint inventory
☐ Supported operating system
☐ Security patches
☐ Malware protection
☐ Disk encryption
☐ Screen lock
☐ Secure configuration
☐ Device management
☐ Remote-wipe capability where appropriate
☐ Lost/stolen-device process
19. Software Installation
Software should be installed through an approved process.
☐ Business need identified
☐ Software source verified
☐ License requirements reviewed
☐ Security risk considered
☐ Approval obtained where required
☐ Installation recorded
☐ Unsupported software removed
Unauthorized or unnecessary software should be investigated.
20. Patch Management
IT systems must be appropriately maintained.
The organization should:
- Identify available security patches.
- Assess relevance and severity.
- Prioritize critical updates.
- Test where appropriate.
- Deploy updates.
- Verify successful installation.
- Record exceptions.
- Track overdue patches.
Patch Register
| System | Patch | Severity | Due Date | Status | Evidence |
|---|---|---|---|---|---|
21. Vulnerability Management
IT operations should support vulnerability management.
☐ Vulnerability scanning
☐ Security testing
☐ Risk assessment
☐ Prioritization
☐ Remediation
☐ Retesting
☐ Exception management
☐ Reporting
Critical vulnerabilities should be handled according to the organization’s defined risk and remediation requirements.
22. Malware Protection
Where applicable:
☐ Endpoint protection
☐ Malware detection
☐ Security alerts
☐ Automatic updates
☐ Quarantine capability
☐ Investigation process
☐ Incident escalation
23. Logging
Appropriate operational and security events should be logged.
Consider logging:
- Authentication
- Privileged activity
- Administrative actions
- Configuration changes
- Security events
- Application events
- Network events
- System events
- Backup events
- Access events
Logs should be protected from unauthorized modification.
24. Monitoring
Critical systems should be monitored according to their risk and availability requirements.
Monitor where appropriate:
☐ System availability
☐ CPU/memory/storage
☐ Network health
☐ Application health
☐ Security alerts
☐ Authentication activity
☐ Backup status
☐ Cloud services
☐ Database health
☐ Certificate expiry
☐ Service availability
Monitoring Thresholds
| Metric | Threshold | Alert | Responsible |
|---|---|---|---|
25. Time Synchronization
Where required, systems should use reliable time synchronization.
Consistent time is important for:
- Security logs
- Incident investigation
- Authentication records
- Audit trails
- Correlation of events
26. Backup Operations
Critical information and systems should be backed up according to business requirements.
☐ Backup scope defined
☐ Backup frequency defined
☐ Backup ownership assigned
☐ Backup protection implemented
☐ Encryption considered
☐ Backup monitoring enabled
☐ Backup failures investigated
☐ Restore testing performed
27. Backup Monitoring
Backup jobs should be monitored.
| Backup | Frequency | Last Successful Run | Status | Owner |
|---|---|---|---|---|
Failed backups should be investigated and corrected according to their criticality.
28. Restore Testing
Backup capability should be periodically tested.
Test:
☐ File restoration
☐ Database restoration
☐ Application restoration
☐ System restoration
☐ Critical service recovery
Record:
- Test date
- Scope
- Expected result
- Actual result
- Recovery time
- Issues
- Corrective actions
29. IT Service Availability
Critical IT services should have defined availability requirements.
| Service | Criticality | Availability Requirement | Owner |
|---|---|---|---|
Where applicable, define:
- RTO
- RPO
- SLA
- Recovery process
- Escalation requirements
30. IT Incident Management
IT incidents must be handled through the organization’s incident-management process.
Examples:
- System outage
- Malware infection
- Account compromise
- Unauthorized access
- Data loss
- Cloud outage
- Network failure
- Backup failure
- Security alert
Process
Detect → Record → Classify → Contain → Investigate → Resolve → Recover → Review
31. Security Event Handling
Not every IT event is a security incident.
Examples:
Event: Multiple failed login attempts.
Assessment: Determine whether this represents normal user activity, a technical issue, or potential attack activity.
Where an event meets defined incident criteria, escalate it to incident management.
32. Change Management
Changes to production IT environments must be controlled.
Before significant changes:
☐ Change request created
☐ Business/technical reason documented
☐ Impact assessed
☐ Security impact assessed
☐ Risk assessed
☐ Approval obtained
☐ Backup/recovery considered
☐ Implementation planned
☐ Rollback plan defined
☐ Testing performed where appropriate
Change Record
| Change | System | Risk | Approval | Date | Result |
|---|---|---|---|---|---|
33. Emergency Changes
Emergency changes may be required to:
- Respond to security incidents
- Restore critical services
- Address critical vulnerabilities
- Prevent significant business impact
Emergency changes should be:
- Authorized according to the emergency process.
- Implemented with appropriate safeguards.
- Documented.
- Reviewed after implementation.
- Tested where appropriate.
34. Job Scheduling and Automated Tasks
For automated operational tasks:
☐ Owner identified
☐ Purpose documented
☐ Permissions restricted
☐ Schedule defined
☐ Failure monitoring enabled
☐ Logs retained
☐ Credentials securely managed
☐ Changes controlled
Examples:
- Backups
- Data processing
- ETL jobs
- Security scans
- Log processing
- Monitoring jobs
- Scheduled reports
35. Database Operations
Database operations should include appropriate controls for:
☐ Administrative access
☐ Authentication
☐ Encryption
☐ Backup
☐ Restore
☐ Monitoring
☐ Logging
☐ Vulnerability management
☐ Patch management
☐ Data retention
☐ Secure deletion
Production database access should be limited to authorized personnel.
36. Storage Management
Monitor critical storage systems for:
- Capacity
- Availability
- Access
- Encryption
- Backup
- Performance
- Unauthorized changes
Storage capacity issues should be addressed before they cause service disruption where practical.
37. Certificate and Domain Management
Maintain visibility over:
- SSL/TLS certificates
- Domains
- DNS
- Certificate expiry
- Renewal responsibility
- Registrar access
Certificate Register
| Certificate/Domain | Owner | Expiry | Renewal Status |
|---|---|---|---|
38. Secrets Management
Operational secrets must be securely managed.
Examples:
- AWS access keys
- API keys
- Database passwords
- SSH keys
- Tokens
- Encryption keys
- Service credentials
☐ Secure storage
☐ Restricted access
☐ Rotation
☐ Expiry where appropriate
☐ Revocation
☐ Monitoring
☐ Compromise response
39. IT Documentation
Maintain appropriate operational documentation.
Examples:
- Network diagrams
- System architecture
- Configuration standards
- Runbooks
- Recovery procedures
- Asset inventory
- Access records
- Change records
- Backup procedures
- Incident procedures
Documentation should be current enough to support safe operation and recovery.
40. IT Runbooks
Critical operational activities should have appropriate runbooks.
Examples:
- Production deployment
- Database restoration
- AWS service recovery
- Certificate renewal
- User access provisioning
- Security incident response
- Backup restoration
- Server recovery
A runbook should provide enough information for an authorized operator to perform the activity consistently.
41. Third-Party IT Services
Where IT operations depend on suppliers:
☐ Supplier identified
☐ Service documented
☐ Security requirements defined
☐ SLA defined where appropriate
☐ Access controlled
☐ Supplier monitored
☐ Security incidents reported
☐ Business continuity considered
☐ Exit arrangements considered
42. IT Support
IT support activities should be recorded where appropriate.
Examples:
- Access requests
- Hardware issues
- Software issues
- Security issues
- Account problems
- Service interruptions
Support Record
| Ticket | User/System | Issue | Priority | Owner | Resolution | Date |
|---|---|---|---|---|---|---|
43. Remote Administration
Remote administrative access must be appropriately secured.
☐ Authorized personnel
☐ MFA
☐ Secure connection
☐ Least privilege
☐ Logging
☐ Monitoring
☐ Access review
☐ Access revocation
Unapproved remote administration methods should not be used.
44. IT Operations During Business Disruption
When normal IT operations are disrupted:
Assess → Prioritize → Activate Recovery → Communicate → Restore → Verify → Record
Critical systems should be restored according to defined recovery priorities.
45. Information Protection
During IT operations:
☐ Information classification respected
☐ Confidential information protected
☐ Restricted information access controlled
☐ Data transfers secured
☐ Temporary files controlled
☐ Production data protected
☐ Sensitive information not unnecessarily copied
46. Operational Security Testing
Where appropriate, perform:
☐ Vulnerability scanning
☐ Configuration review
☐ Penetration testing
☐ Backup restoration testing
☐ Access review
☐ Security monitoring validation
☐ Disaster recovery testing
☐ Incident-response testing
Testing should be authorized and conducted without unnecessarily disrupting production services.
47. IT Operations Review
Review IT operations periodically.
Consider:
- System availability
- Security incidents
- Vulnerabilities
- Patch status
- Backup status
- Access reviews
- Changes
- Operational failures
- Supplier performance
- Capacity
- Security alerts
- Compliance requirements
- Open corrective actions
48. IT Operations Metrics
Possible metrics include:
| Metric | Target | Frequency |
|---|---|---|
| Critical system availability | ||
| Critical patch compliance | ||
| Backup success rate | ||
| Critical vulnerability remediation | ||
| Access review completion | ||
| Change success rate | ||
| Security incident response | ||
| IT ticket SLA |
Metrics should support operational and security decision-making rather than simply creating additional reporting.
49. Exceptions
Exceptions to IT operational requirements must be:
☐ Documented
☐ Justified
☐ Risk assessed
☐ Approved
☐ Time-bound where appropriate
☐ Monitored
☐ Reviewed
☐ Closed or formally accepted
50. IT Operations Findings
Record identified weaknesses.
| Finding ID | Area | Finding | Risk | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|---|---|
51. Corrective Action
For significant weaknesses:
- Identify the issue.
- Determine the root cause.
- Apply immediate correction where necessary.
- Define corrective action.
- Assign an owner.
- Establish a due date.
- Implement the action.
- Verify effectiveness.
- Assess residual risk.
- Close the action.
52. IT Operations Evidence
Maintain appropriate evidence such as:
☐ Asset inventory
☐ Configuration records
☐ Access approvals
☐ Access reviews
☐ Change records
☐ Patch reports
☐ Vulnerability reports
☐ Monitoring alerts
☐ Backup reports
☐ Restore tests
☐ Incident records
☐ Support tickets
☐ Security logs
☐ Supplier records
☐ IT review records
Do not retain unnecessary passwords, private keys, API secrets, or authentication credentials as evidence.
53. IT Operations Review Frequency
The frequency of operational reviews should be based on:
- System criticality
- Security risk
- Business impact
- Regulatory requirements
- Customer requirements
- Change frequency
- Incident history
- Supplier dependency
Example:
| Activity | Suggested Frequency |
|---|---|
| Security monitoring | Continuous |
| Backup monitoring | Daily/Continuous |
| Critical patch review | Weekly |
| Vulnerability review | Weekly/Monthly |
| Access review | Quarterly or risk-based |
| Asset review | Quarterly |
| Configuration review | Quarterly |
| Supplier review | Risk-based |
| Disaster recovery testing | Periodic |
| IT operations review | Monthly/Quarterly |
These frequencies should be adapted to the organization’s actual risk and requirements.
54. AWS SaaS Startup Example
Environment
A SaaS startup operates:
- AWS production environment
- RDS database
- S3 storage
- GitHub
- CI/CD pipeline
- CloudFront
- Route 53
- Employee laptops
- SaaS productivity tools
Daily Operations
☐ Review critical security alerts
☐ Check production availability
☐ Review backup status
☐ Review critical failures
☐ Review monitoring alerts
Weekly Operations
☐ Review critical vulnerabilities
☐ Review patch status
☐ Review failed backups
☐ Review important operational alerts
☐ Review expiring certificates
Monthly Operations
☐ Review cloud configuration
☐ Review privileged access
☐ Review asset inventory
☐ Review operational metrics
☐ Review open IT findings
☐ Review supplier issues
Quarterly Operations
☐ Access review
☐ Configuration review
☐ Vulnerability trend review
☐ Backup restoration test where appropriate
☐ IT risk review
☐ Supplier/security review where required
Example Evidence
AWS CloudTrail logs → CloudWatch alerts → Backup reports → Vulnerability reports → IAM review → Change tickets → Incident records → Monthly IT operations report
55. Startup-Friendly IT Operations Model
A small startup can keep IT operations simple while maintaining strong control.
Daily
Monitor → Backup → Security Alerts → Critical Issues
Weekly
Patch → Vulnerability → Backup Failures → Operational Review
Monthly
Access → Configuration → Assets → Metrics → Open Findings
Quarterly
Risk → Access → Suppliers → Recovery → Security Review
Event-Driven
Incident → Change → New System → New Supplier → Major Vulnerability → Business Disruption
The objective is not to create unnecessary administrative work. The objective is to ensure that critical IT activities happen consistently and can be demonstrated through evidence.
56. Common Mistakes
Avoid:
- Operating production systems without defined ownership.
- Granting permanent privileged access unnecessarily.
- Using shared administrator accounts.
- Storing credentials in scripts or source code.
- Making production changes without records.
- Ignoring failed backups.
- Assuming successful backup means successful recovery.
- Failing to monitor certificate expiry.
- Allowing unsupported software.
- Ignoring critical vulnerabilities.
- Failing to review cloud configurations.
- Treating monitoring alerts as automatically resolved.
- Keeping unnecessary production data in test environments.
- Failing to document emergency changes.
- Not maintaining operational runbooks.
- Depending on one employee’s undocumented knowledge.
- Collecting excessive operational evidence without protecting it.
57. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Information Security Policy | Governs information-security objectives |
| IT Security Policy | Defines IT-security requirements |
| Asset Management Procedure | Manages IT assets |
| Access Control Procedure | Controls user access |
| Change Management Procedure | Controls IT changes |
| Vulnerability Management Procedure | Manages vulnerabilities |
| Patch Management Procedure | Manages security updates |
| Backup & Restore Procedure | Protects recoverability |
| Incident Response Procedure | Handles incidents |
| Business Continuity Plan | Handles major disruption |
| Disaster Recovery Plan | Restores technology services |
| Cloud Security Policy | Governs cloud environments |
| Supplier Security Procedure | Manages IT suppliers |
| Logging & Monitoring Procedure | Manages operational/security monitoring |
| Risk Assessment | Identifies IT operational risks |
| Statement of Applicability | Records applicable controls |
| Corrective Action Tracker | Tracks identified weaknesses |
58. ISO/IEC 27001 Connection
The IT Operations Procedure supports the organization’s ISMS by translating applicable information-security requirements into controlled operational activities.
The exact operational controls and procedures required should be determined based on:
- ISMS scope
- Risk assessment
- Risk treatment
- Statement of Applicability
- Applicable Annex A controls
- Business requirements
- Technology architecture
- Legal/regulatory requirements
- Customer requirements
- Contractual requirements
This procedure is not itself a universally prescribed ISO/IEC 27001 document. The organization should document and maintain the operational information necessary to support controlled processes and retain appropriate evidence of execution.
59. Audit Evidence Checklist
An auditor should be able to trace:
☐ IT environment
☐ Asset ownership
☐ Access controls
☐ Privileged access
☐ Secure configuration
☐ Patch management
☐ Vulnerability management
☐ Logging
☐ Monitoring
☐ Backup
☐ Restore testing
☐ Change management
☐ Incident management
☐ Supplier management
☐ Operational reviews
☐ Findings
☐ Corrective actions
☐ Exceptions
☐ Management oversight
60. Final IT Operations Audit Trail
For critical IT operations, the organization should be able to demonstrate:
What systems do we operate?
Who owns them?
What information do they process?
What risks do they introduce?
Who has access?
How are systems securely configured?
How are vulnerabilities and patches managed?
How are systems monitored?
How are backups performed and tested?
How are changes controlled?
How are incidents handled?
How is operational evidence retained?
How do we know IT operations are effective?
Final Principle
IT operations are not simply about keeping systems running. Effective IT operations ensure that systems are securely configured, appropriately accessed, monitored, maintained, recoverable, and supported by evidence.
