"CERT-In-ready SOC" — runbooks and staffing
To meet the 6-hour reporting requirement consistently, MSPs must establish a Security Operations Center (SOC) with specific capabilities and processes designed for CERT-In compliance. Key elements include:
On-call model, severity matrix, and reporting authority
A CERT-In-ready SOC requires a well-defined operational model that ensures continuous monitoring and rapid response:
- 24×7 coverage model with clear shift handover procedures
- Tiered analyst structure with escalation paths for potential reportable incidents
- Severity classification matrix that aligns with CERT-In reportable incident categories
- Decision authority framework designating who can authorize CERT-In reports
- SLA tracking mechanisms to monitor time-to-report metrics
The severity matrix should clearly define criteria for each incident type, helping analysts quickly determine whether an event meets the reporting threshold. The decision authority framework should designate specific roles authorized to approve and submit reports to CERT-In, ensuring that reports can be sent within the 6-hour window even during non-business hours.
Tabletop exercises
Regular testing of incident response and reporting procedures is essential to ensure readiness for actual incidents:
- Quarterly tabletop exercises simulating different reportable incident scenarios
- Role-specific training for all SOC team members on CERT-In requirements
- Cross-functional exercises involving technical teams, management, and legal/compliance
- Scenario-based testing of detection, analysis, and reporting workflows
- Post-exercise reviews to identify and address process gaps
These exercises should test the end-to-end incident response process, from initial detection through analysis, decision-making, and report preparation. Scenarios should cover various incident types specified in the CERT-In Directions, with particular attention to complex scenarios that test the limits of the 6-hour reporting window.
Proving response time
MSPs must maintain comprehensive documentation to demonstrate compliance with the 6-hour reporting requirement during audits or investigations:
- Timestamped incident records documenting detection, analysis, and reporting activities
- System-generated audit logs corroborating manual documentation
- Report submission receipts from CERT-In portal or email communications
- SLA compliance reports showing historical performance against the 6-hour requirement
- Process documentation demonstrating how the organization ensures timely reporting
This documentation should be maintained in a secure, easily accessible repository to support audit readiness. Regular reviews of documentation completeness and accuracy should be conducted to ensure that evidence of compliance is always available.
Technical blueprint
Reference architecture: SIEM/SOAR + log pipelines + immutable storage
A robust technical architecture is the foundation for CERT-In compliance. The reference architecture should include:
- Distributed log collection agents deployed across all managed systems
- Log forwarding infrastructure with redundancy and failure handling
- SIEM platform for log aggregation, normalization, and correlation
- SOAR capabilities for automated incident triage and response
- Immutable storage solution for tamper-proof log retention
- Data sovereignty controls ensuring logs remain within India
- Search and retrieval mechanisms for rapid incident investigation
This architecture should be designed for scalability, reliability, and compliance with the 180-day retention requirement. Performance considerations are critical, as the system must support both real-time analysis for incident detection and historical searches for investigations.
Alerting: identity, privileged access, exfil, ransomware, outage
Effective alerting is essential for detecting reportable incidents within the timeframe required for CERT-In compliance. Key alert categories include:
- Identity-based alerts for account compromise, privilege escalation, and unauthorized access
- Privileged access monitoring for administrative account misuse and unauthorized actions
- Data exfiltration detection for unusual outbound data transfers and potential breaches
- Ransomware indicators including file encryption activities and known malware signatures
- Service availability monitoring for outages and denial of service conditions
- Network-based detection for scanning, lateral movement, and command-and-control traffic
These alerts should be tuned to balance sensitivity with precision, ensuring that potential reportable incidents are detected quickly while minimizing false positives that could overwhelm the SOC team.
Controls that reduce false positives but protect reporting windows
To manage the challenge of meeting the 6-hour reporting window while avoiding unnecessary reports, MSPs should implement:
- Multi-stage alert validation with automated enrichment of initial detections
- Baseline-aware detection that considers normal patterns for each environment
- Correlation rules that combine multiple indicators to reduce false positives
- Machine learning-based anomaly detection to identify unusual behaviors
- Automated playbooks for initial triage and evidence collection
- Risk-based prioritization to focus analyst attention on the most critical alerts
These controls should be continuously refined based on performance metrics and lessons learned from both real incidents and exercises. The goal is to create a detection and triage process that reliably identifies reportable incidents while filtering out false positives, all within a timeframe that allows for proper analysis and reporting within the 6-hour window.
Compliance evidence pack
Incident Response SOP aligned to CERT-In
A comprehensive Incident Response Standard Operating Procedure (SOP) is essential for CERT-In compliance. This document should include:
- Incident classification framework aligned with CERT-In reportable incident categories
- Detection and triage procedures with clear responsibilities and timelines
- Escalation paths for potential reportable incidents
- Analysis and validation workflows with decision criteria
- Reporting procedures including templates and submission methods
- Post-incident activities including documentation and lessons learned
- Contact information for CERT-In and other relevant authorities
The SOP should emphasize the 6-hour reporting requirement and include process flows that ensure this timeline can be met consistently. It should be regularly reviewed and updated based on changes to CERT-In requirements, lessons from incidents, and feedback from exercises.
Log retention policy and system design note
A formal Log Retention Policy and accompanying System Design Note should document the approach to meeting the 180-day retention requirement. These documents should cover:
- Scope of log collection identifying all systems subject to the requirement
- Log types and formats to be collected from each system
- Collection mechanisms and transport security
- Storage architecture including capacity planning and scaling
- Retention periods and deletion procedures
- Access controls and audit logging for the log repository
- Backup and recovery procedures for the log management system
- Data sovereignty controls ensuring logs remain within India
The System Design Note should provide technical details on the implementation, including component specifications, data flows, and security controls. This documentation serves both as an operational reference and as evidence of compliance during audits.
Time sync policy + monitoring report
A Time Synchronization Policy and accompanying Monitoring Report template should document the approach to meeting the NTP synchronization requirement. These documents should include:
- NTP server architecture with primary and secondary time sources
- Traceability documentation showing alignment with NIC or NPL time sources
- Configuration standards for different system types
- Monitoring approach including metrics and thresholds
- Alerting procedures for synchronization issues
- Remediation workflows for addressing time drift
- Reporting templates showing compliance status across the environment
The Monitoring Report should provide a snapshot of time synchronization status across the environment, highlighting any systems that are out of compliance and documenting remediation actions. This report should be generated regularly to demonstrate ongoing compliance with the time synchronization requirement.
FAQs
Is the 6-hour clock from detection or confirmation?The 6-hour reporting timeline begins from the point of detection or notification of the incident, not from the point of confirmation. This interpretation is based on the language in the CERT-In Directions, which states that organizations must report "within 6 hours of noticing such incidents or being brought to notice about such incidents."
This means that MSPs must establish efficient triage and validation processes to quickly determine whether a detected event constitutes a reportable incident. While thorough analysis is important to avoid unnecessary reports, the process must be designed to complete within the 6-hour window, even for complex incidents.
Best practice is to implement a staged approach where initial detection triggers immediate triage, followed by rapid validation and escalation for potential reportable incidents. The final determination and report preparation should be completed with enough margin to ensure submission within the 6-hour window.
What logs count, and what's the minimum retention design?The CERT-In Directions require retention of "all logs of all ICT systems" for a period of 180 days within Indian jurisdiction. This broad language encompasses a wide range of log types, including:
- System logs (operating system events, authentication, authorization)
- Application logs (web servers, databases, business applications)
- Security logs (firewalls, IDS/IPS, endpoint protection)
- Network logs (routers, switches, load balancers)
- Cloud service logs (infrastructure, platform, and software services)
The minimum retention design should include:
- Centralized log collection infrastructure with agents or forwarders on all systems
- Tiered storage architecture balancing performance and cost
- Tamper-evident controls to prevent unauthorized modification
- Access controls restricting who can view or manage logs
- Search and retrieval capabilities for incident investigation
- Data sovereignty controls ensuring logs remain within India
Organizations should implement a risk-based approach to log verbosity, capturing detailed logs for critical systems while implementing more selective logging for lower-risk systems, all while ensuring that security-relevant events are consistently captured across the environment.
How do we handle multi-tenant MSP logging and customer data separation?Multi-tenant environments present unique challenges for CERT-In compliance, particularly around log management and incident reporting. Best practices for managing these challenges include:
- Logical separation of logs using tenant identifiers or separate log stores
- Role-based access controls restricting visibility to authorized personnel
- Clear contractual language defining responsibilities for incident reporting
- Customer notification procedures for incidents affecting their environments
- Tenant-aware incident response processes that respect data separation
MSPs should implement technical controls that maintain separation between tenant data while still enabling efficient log collection and analysis. This typically involves tagging logs with tenant identifiers at the point of collection and enforcing access controls throughout the log management lifecycle.
Service agreements should clearly define the roles and responsibilities of the MSP and the customer in meeting CERT-In requirements, particularly around incident reporting and log retention. These agreements should address scenarios where incidents affect multiple tenants and establish protocols for coordinating responses while maintaining appropriate separation.
Expert Guidance for Your CERT-In Compliance Journey
Implementing CERT-In compliance requirements involves complex technical and operational considerations. Our team of security and compliance specialists can help you design and implement a comprehensive CERT-In compliance program tailored to your MSP environment. Contact us today for a consultation on your specific compliance needs.
Related Compliance Resources
DPDP Compliance
Understand how CERT-In requirements intersect with India's Digital Personal Data Protection Act and develop integrated compliance strategies.
Financial Sector Compliance
Explore how RBI, SEBI, and IRDAI regulations align with CERT-In requirements for MSPs serving financial sector clients.
ISO 27001 Alignment
Discover how to integrate CERT-In compliance requirements into your existing ISO 27001 Information Security Management System.
Conclusion
The CERT-In Directions 2022 represent a significant evolution in India's cybersecurity regulatory landscape, imposing specific and time-sensitive requirements on MSPs and other service providers. Successfully implementing these requirements demands a combination of technical infrastructure, operational processes, and organizational readiness.
By establishing robust incident detection and reporting capabilities, implementing comprehensive log management solutions, ensuring accurate time synchronization, and maintaining appropriate documentation, MSPs can achieve compliance while enhancing their overall security posture. These capabilities not only satisfy regulatory requirements but also improve the MSP's ability to protect both their own environment and those of their clients.
As the regulatory landscape continues to evolve, MSPs that establish strong foundations for CERT-In compliance will be well-positioned to adapt to new requirements and maintain the trust of their clients. By treating compliance as an opportunity to enhance security capabilities rather than simply a regulatory burden, MSPs can derive strategic value from their compliance investments.