The Complete Guide to CERT-In Compliance: Step-by-Step for Indian Organizations

India reported 1.39 million+ cybersecurity incidents in 2022 alone (CERT-In Annual Report 2022), yet fewer than 15% of Indian enterprises have fully operationalized CERT-In's 6-hour incident reporting mandate. The consequence — non-compliance isn't theoretical. CERT-In has the power to block services, mandate audits, and the IT Act 2000 carries penalties including imprisonment. What makes this guide different — this is a practitioner implementation guide mapped to each CERT-In directive, not a summary of what the rules say.

What is CERT-In and Why It Matters Now

The Indian Computer Emergency Response Team (CERT-In) was established under Section 70B of the IT Act 2000 as the nodal agency for cybersecurity incident response under the Ministry of Electronics and Information Technology (MeitY). What began as an advisory body has evolved into an enforcement agency with the April 2022 Directions, fundamentally changing the compliance landscape for every organization operating computer systems in India.

Unlike sectoral regulators, CERT-In's jurisdiction extends to ALL organizations with computer systems — not just IT companies. A 10-person fintech startup faces the same 6-hour incident reporting obligation as Tata Consultancy Services. There are no revenue thresholds, employee count exemptions, or grace periods for compliance.

The organizational structure matters for compliance. CERT-In operates under Dr. Sanjay Bahl as Director General, with specialized teams for incident response, vulnerability coordination, and threat intelligence. The agency maintains 24x7 operations and expects the same availability from designated organizational contacts.

CERT-In's relationship with other regulators creates a compliance web many organizations navigate poorly. The Reserve Bank of India's IT Governance Framework, SEBI's Cyber Security and Cyber Resilience Framework, IRDAI's cybersecurity guidelines, and the Digital Personal Data Protection Act 2023 all intersect with CERT-In obligations. Organizations subject to multiple regulators often build separate compliance programs — a costly mistake.

SARC's CERT-In Compliance Stack

To understand these overlapping obligations, we've developed the CERT-In Compliance Stack — a four-layer model showing how cyber regulations interact:

Layer 4: Data Protection — DPDP Act breach notification requirements ("without delay") Layer 3: Sector-Specific — RBI, SEBI, IRDAI cyber frameworks with sector-specific controls Layer 2: National Cyber Response — CERT-In Directions (6-hour reporting, log retention, NTP sync) Layer 1: Legal Foundation — IT Act 2000 penalties and enforcement mechanisms

The stack reveals a critical insight: organizations that build for the most demanding intersection — typically CERT-In plus their sector regulator — automatically satisfy other requirements. Don't build four compliance programs. Build one robust program and map it to four frameworks.

The enforcement reality has shifted dramatically. Pre-2022, CERT-In issued advisories. Post-April 2022, they issue directions with legal enforceability. The agency has conducted surprise audits on major Indian enterprises, mandated security improvements, and in extreme cases, blocked services. The cost of non-compliance now includes operational disruption, not just reputational damage.

The April 2022 CERT-In Directions — Clause-by-Clause Implementation

The CERT-In Directions of April 28, 2022, represent the most significant expansion of cyber compliance obligations in Indian corporate history. Every directive carries implementation challenges that theoretical guides ignore. Here's the practitioner reality:

6-Hour Incident Reporting: The Headline Mandate

The 6-hour incident reporting requirement covers 20 categories of cybersecurity incidents, from targeted scanning to ransomware attacks. The clock starts when the organization becomes aware of the incident — not when it occurred. This distinction trips up most compliance teams.

Consider a practical scenario: An Indian private bank's security operations center detects unusual data exfiltration at 2:00 AM on Saturday. The SOC analyst follows protocol, escalating to the weekend duty manager at 2:30 AM. The duty manager contacts the CISO at 3:15 AM. The 6-hour reporting window begins at 3:15 AM — when the organization (through its designated authority) became aware. The report must reach CERT-In by 9:15 AM, regardless of investigation status.

Most organizations build elaborate investigation workflows before reporting. This approach violates the directive. CERT-In wants notification first, detailed analysis later. The initial report can be preliminary — "We detected unauthorized access to our customer database. Investigation ongoing. Full report to follow within 24 hours." Complete accuracy isn't expected within 6 hours. Timely notification is.

Reporting mechanism requires [email protected] with specific fields: incident type, affected systems, initial assessment, containment actions, and estimated impact. Organizations should maintain pre-drafted templates for each of the 20 incident categories to accelerate reporting.

The contrarian insight: Most organizations focus on incident response. The critical gap is incident detection. Advanced persistent threats remain undetected in Indian networks for months. The 6-hour rule assumes you know about the incident. Investment in detection capabilities — SIEM, EDR, NDR — delivers more compliance value than incident response process optimization.

180-Day Log Retention: The Storage Challenge

All ICT system logs must be retained for 180 days within Indian jurisdiction. This seems straightforward until you inventory actual log sources. The requirement covers firewall logs, IDS/IPS alerts, web server access logs, mail server logs, database audit logs, application logs, VPN connection logs, authentication logs, DNS query logs, and DHCP lease logs.

A mid-size NBFC using Amazon Web Services discovered their default CloudWatch log retention was 90 days. CloudTrail audit logs defaulted to 30 days. VPC Flow Logs weren't enabled. Their compliance gap: 60% of required logs weren't retained for the mandated period, and existing logs were in AWS Singapore region, not India.

The compliance fix required:

• Migrating all log storage to AWS Mumbai region
• Extending CloudWatch retention to 180 days (cost increase: 4x)
• Enabling VPC Flow Logs with 180-day retention
• Implementing CloudTrail organization trail with 180-day retention
• Creating S3 lifecycle policies for automated log management

Log storage costs scale dramatically. A 500-employee organization generates approximately 2-4 TB of logs monthly. At 180-day retention, storage requirements reach 12-24 TB with backup. Cloud storage costs in India regions: ₹1.5-3 lakh monthly for compliant log retention.

Tamper-proofing requirements add complexity. Logs must be protected against unauthorized modification. Most organizations implement write-once storage (AWS S3 Object Lock, Azure Immutable Blob Storage) or dedicated log management platforms with integrity verification.

Time synchronization becomes critical for forensic correlation. All systems must synchronize to Network Time Protocol (NTP) servers operated by National Informatics Centre (NIC) or National Physical Laboratory (NPL). During a multi-stage attack on an Indian power utility, mismatched timestamps between IT and OT systems made forensic reconstruction impossible. NTP synchronization across enterprise and operational technology systems isn't just compliance — it's investigative necessity.

Designated Point of Contact: The Human Element

Every organization must register a Point of Contact (PoC) available 24x7 for incident coordination. Registration occurs through CERT-In's portal at cert-in.org.in. The PoC receives incident advisories, coordination requests, and emergency communications.

The human challenge: cybersecurity professionals change jobs frequently. The designated PoC at a major Indian IT services company left for a startup. Six months later, CERT-In attempted emergency coordination during a supply chain attack. The contact bounced. The organization faced potential enforcement action for an administrative oversight.

Best practice: Designate a role-based contact ([email protected]) with backup individuals. Update within 7 days of any change. Maintain current mobile numbers for emergency coordination. Test quarterly with internal coordination drills.

VPN and Virtual Asset Provider Requirements

VPN service providers must maintain subscriber records for 5 years: validated names, addresses, contact numbers, subscription periods, assigned IP addresses, email addresses with timestamps, and purpose of service usage. Virtual asset service providers and cryptocurrency exchanges face identical requirements plus KYC data and financial transaction records.

Data center and cloud service providers must retain customer information for 5 years after service cancellation. This affects enterprises indirectly — cloud providers may pass compliance costs to customers, and service level agreements may change to accommodate Indian data retention requirements.

The practical impact: International VPN providers may exit the Indian market rather than comply with subscriber data retention. Organizations using VPNs for remote access should audit provider compliance status and maintain alternative solutions.

Who Must Comply: The Applicability Matrix

CERT-In Directions apply universally to organizations operating computer systems in India. Unlike the Digital Personal Data Protection Act, which exempts small entities, CERT-In makes no size-based distinctions. The compliance matrix reveals surprising scope:

The "operates computer systems" threshold is lower than most organizations assume. A chartered accountancy firm with email servers, client data management systems, and internet connectivity falls under CERT-In jurisdiction. A manufacturing company with ERP systems and industrial IoT devices faces full compliance obligations.

Startups represent a significant compliance challenge. A 15-person fintech with limited security expertise faces identical reporting obligations as established banks. The directive provides no startup exemption, compliance scaling, or implementation timeline flexibility.

The 20 Reportable Incident Categories: What Triggers Reporting

CERT-In's incident categories cover the full spectrum of cyber threats. Understanding reporting triggers prevents both over-reporting (administrative burden) and under-reporting (compliance violation):

Category 1: Targeted Scanning/Probing — Automated port scans don't qualify. Targeted reconnaissance of critical systems by known threat actors triggers reporting. Example: APT group scanning specific banking applications.

Category 2: Critical System Compromise — Any unauthorized access to systems classified as critical infrastructure. Definition includes financial systems, power grids, telecommunications, and government networks.

Category 3: Unauthorized Access — Successful breach of authentication controls, including privileged account compromise, lateral movement, and data access without authorization.

Category 4: Website Defacement — Visible alteration of web properties, including subdomain defacement and content management system compromise.

Category 5: Malicious Code — Ransomware, worms, trojans, and advanced persistent threat malware. Includes attempted deployment even if blocked by security controls.

Category 6: Server Attacks — Compromise of database, mail, DNS, and application servers through exploitation or misuse of legitimate access.

Category 7: Identity Theft/Spoofing — Phishing campaigns targeting organizational credentials, business email compromise, and social engineering attacks.

Category 8: Denial of Service — Volumetric, protocol, and application-layer DDoS attacks causing service degradation or unavailability.

Category 9: Critical Infrastructure — Attacks specifically targeting power, transport, finance, telecommunications, and government systems with potential national impact.

Category 10: IoT/SCADA/OT Attacks — Compromise of Internet of Things devices, industrial control systems, and operational technology networks.

Category 11: Digital Payment Attacks — Unauthorized transactions, payment gateway compromise, and digital wallet fraud affecting financial systems.

Category 12: Malicious Mobile Apps — Deployment of trojanized mobile applications targeting organizational data or systems.

Category 13: Fake Mobile Apps — Creation of counterfeit applications impersonating legitimate organizational services.

Category 14: Social Media Compromise — Unauthorized access to official organizational social media accounts used for business purposes.

Category 15: Cloud System Attacks — Compromise of cloud-hosted infrastructure, applications, or data, including configuration exploitation.

Category 16: AI/ML System Attacks — Adversarial attacks against artificial intelligence systems, model poisoning, and algorithmic manipulation.

Category 17: Supply Chain Attacks — Compromise through trusted third parties, software supply chain poisoning, and vendor-mediated breaches.

Category 18: Data Breach/Leak — Unauthorized disclosure of sensitive information through technical compromise or human error.

Category 19: Ransomware — Crypto-malware deployment with or without successful encryption, including ransom demands.

Category 20: Cryptojacking — Unauthorized cryptocurrency mining using organizational computing resources.

A common compliance question: Does attempted attack that was blocked require reporting? Answer depends on targeting sophistication. Generic malware blocked by antivirus doesn't qualify. Targeted spear-phishing blocked by email security but specifically crafted for your organization does qualify under Category 7.

The reporting threshold isn't successful compromise — it's targeted attack against organizational systems. A distributed denial of service attack that was mitigated by cloud protection still requires reporting under Category 8 because it targeted your specific infrastructure.

CERT-In Compliance Architecture: The SARC Implementation Framework

Effective CERT-In compliance requires systematic architecture spanning detection, reporting, retention, response, and governance. Our five-layer CERT-In Readiness Framework provides implementation structure:

Layer 1: DETECT (Mean Time to Detection Under 1 Hour)

Detection capability determines compliance feasibility. Organizations that can't detect incidents within hours struggle with 6-hour reporting obligations. Essential detection components:

Security Information and Event Management (SIEM): Centralized log analysis across all systems with correlation rules for the 20 incident categories. Indian deployment considerations include data residency requirements and integration with local threat intelligence feeds.

Network Detection and Response (NDR): Deep packet inspection and traffic analysis to identify lateral movement, command-and-control communication, and data exfiltration attempts.

Endpoint Detection and Response (EDR): Host-based monitoring for malware deployment, privilege escalation, and suspicious process execution across workstations and servers.

Threat Intelligence Integration: CERT-In advisories, NCIIPC alerts, and commercial threat feeds tailored for Indian threat landscape and attack patterns.

Cloud Security Posture Management: Configuration monitoring and anomaly detection for cloud-hosted infrastructure and applications.

Target metrics: Mean Time to Detection (MTTD) under 1 hour for critical incidents, 100% log source coverage, zero blind spots in network visibility.

Layer 2: REPORT (Incident-to-Notification Under 4 Hours)

Reporting capability requires pre-built processes, templates, and decision authority. Key components:

Incident Classification Playbooks: Decision trees for each of the 20 categories with specific examples and escalation triggers. Reduces classification ambiguity during high-stress incidents.

Pre-Drafted Report Templates: Standard incident report formats for each category with mandatory fields pre-populated. Enables rapid reporting without administrative delay.

24x7 Escalation Matrix: Clear decision authority for incident reporting with backup contacts and mobile accessibility. Eliminates "who can approve the report" delays.

Secure Communication Channels: Dedicated email accounts and encrypted communication for CERT-In coordination separate from standard corporate email.

Automated Reporting Integration: API-based or email automation for standard incident types to reduce manual reporting time.

Target metrics: Time from detection to CERT-In notification under 4 hours, 100% reporting accuracy for incident categorization, zero missed reporting deadlines.

Layer 3: RETAIN (100% Log Coverage, Zero Gaps)

Log retention architecture must satisfy CERT-In requirements while supporting forensic analysis and compliance auditing:

180-Day Rolling Retention: Automated log lifecycle management with compliance-grade storage in Indian jurisdiction. Includes backup and disaster recovery for log data.

Log Integrity Mechanisms: Write-once storage, cryptographic hashing, and tamper-evident logging to maintain forensic integrity and compliance auditing.

Network Time Protocol Synchronization: Enterprise-wide time synchronization to Indian standard time sources for accurate incident correlation and forensic analysis.

Comprehensive Log Coverage: All required log sources including infrastructure, application, security, and access logs with standardized format and retention policies.

Log Query and Analysis: Rapid search and analysis capabilities for incident investigation and CERT-In coordination with appropriate access controls.

Target metrics: 180-day retention compliance for 100% of required log sources, zero gaps in log collection, tamper-proof storage with integrity verification.

Layer 4: RESPOND (Mean Time to Contain Under 24 Hours)

Incident response capabilities must align with CERT-In coordination requirements and enable effective containment:

Incident Response Plan: Documented procedures for each attack category with containment, eradication, and recovery steps aligned to business operations.

Evidence Preservation: Forensic data collection and preservation protocols to support CERT-In investigation requests and potential law enforcement coordination.

Communication Protocols: Internal stakeholder notification, regulatory reporting, and public communication procedures with approval workflows and message templates.

Containment Procedures: Technical response capabilities for network isolation, system quarantine, and attack chain disruption with minimal business impact.

Post-Incident Analysis: Structured lessons learned and improvement processes to strengthen detection and response capabilities based on actual incidents.

Target metrics: Mean Time to Contain (MTTC) under 24 hours, 100% evidence preservation for CERT-In requests, zero business disruption from containment actions.

Layer 5: GOVERN (Zero Compliance Gaps)

Governance layer ensures sustainable compliance and continuous improvement:

CERT-In PoC Management: Designated point of contact registration, maintenance, and backup coordination with 24x7 availability verification.

Compliance Self-Assessment: Quarterly internal audits against CERT-In requirements with gap identification and remediation tracking.

Mock Incident Exercises: Annual tabletop exercises and technical simulations to test incident response and reporting capabilities under realistic conditions.

Board Reporting: Regular cybersecurity metrics reporting to leadership including incident trends, compliance status, and risk exposure.

Third-Party Risk Management: Vendor and partner compliance verification to ensure supply chain adherence to CERT-In requirements.

Target metrics: Zero compliance gaps in annual audit, 100% PoC availability, quarterly board reporting on cyber incident metrics.

CERT-In vs RBI vs SEBI vs DPDP: The Multi-Regulator Compliance Map

Indian enterprises increasingly face multiple cyber regulatory obligations simultaneously. Financial services companies must satisfy CERT-In, RBI, and DPDP requirements. Listed companies navigate CERT-In, SEBI, and DPDP obligations. The compliance overlap creates both complexity and optimization opportunities:

The optimization insight: Organizations building for the most demanding intersection automatically satisfy other requirements. A bank implementing 5-year log retention (SEBI requirement) exceeds CERT-In's 180-day mandate. A company with 6-hour incident reporting (CERT-In) can easily satisfy DPDP's "without delay" breach notification.

Practical implementation: Build one robust cyber compliance program and map it to multiple frameworks rather than maintaining separate programs for each regulator. The marginal cost of multi-regulator compliance is lower than the total cost of separate compliance programs.

Regulatory coordination remains limited. CERT-In and sector regulators don't automatically share incident reports. Organizations may need to file separate reports for the same incident with different regulators using different formats and timelines.

Common Compliance Failures: What Audits Actually Find

CERT-In empanelled auditors consistently identify similar compliance gaps across industries and organization sizes. These failures pattern predictably:

Log Coverage Blindspots

Organizations implement comprehensive application logging but miss critical infrastructure logs. Common gaps include firewall rule changes, DNS query logs, DHCP lease assignments, and network device configuration changes. A major Indian retailer maintained detailed e-commerce transaction logs but couldn't produce firewall logs during a CERT-In investigation of customer data exfiltration.

The fix requires comprehensive log source inventory mapping to CERT-In requirements. Every network device, server, application, and security control must generate compliant logs with 180-day retention.

NTP Synchronization Drift

Operational technology (OT) systems in manufacturing and power generation often run independent time sources, creating forensic correlation problems. During investigation of a ransomware attack on an Indian steel manufacturer, IT system logs showed attack timeline from 10:30 AM to 11:15 AM. OT system logs for the same attack showed 10:45 AM to 11:30 AM due to 15-minute clock drift. Forensic reconstruction became impossible.

Enterprise NTP synchronization must extend to operational technology, IoT devices, and air-gapped systems with offline time synchronization procedures.

Incident Reporting Confusion

Security teams struggle with reporting thresholds. A blocked phishing email targeting the CFO — is this reportable? Answer: If the phishing was specifically crafted for your organization (spear-phishing), yes under Category 7. If it was generic phishing blocked by email filters, no.

The distinction requires threat intelligence analysis and attack attribution. Organizations need clear escalation criteria and when-in-doubt reporting protocols.

Point of Contact Maintenance Gaps

Cybersecurity professionals change positions frequently. The designated PoC at a major Indian pharmaceutical company departed for a consulting role. Eight months later, CERT-In attempted coordination during a supply chain attack. Email bounced, mobile number was disconnected. The organization faced enforcement action for administrative failure.

Best practice: Role-based email addresses ([email protected]) with multiple individual backups, quarterly contact verification, and immediate update procedures.

Cloud Responsibility Confusion

Organizations assume cloud providers handle CERT-In compliance automatically. A fintech using Google Cloud discovered their audit logs defaulted to 90-day retention in Singapore region. CERT-In compliance required 180-day retention in Indian region with customer configuration.

Cloud shared responsibility models require explicit compliance configuration. Default cloud settings rarely satisfy Indian regulatory requirements.

Incident Response Without Testing

Incident response plans exist on paper but teams haven't tested procedures under realistic conditions. During actual incidents, escalation chains fail, report templates can't be located, and CERT-In coordination delays occur.

Annual tabletop exercises and technical simulations identify procedural gaps before real incidents occur.

Six-Hour Window Misunderstanding

Teams interpret "6 hours" as business hours or standard work days. CERT-In means 6 clock hours including weekends, holidays, and overnight periods. A ransomware attack detected Friday evening must be reported by Friday midnight, not Monday morning.

Compiance requires true 24x7 reporting capability with weekend and holiday escalation procedures.

Implementation Costs: Realistic Compliance Budgets

CERT-In compliance costs vary significantly based on organizational size, existing security maturity, and implementation approach. These estimates reflect Indian market pricing for 2024-2025:

Small Organizations (50-200 employees)

Detection Infrastructure:

• Cloud-based SIEM (Microsoft Sentinel, Splunk Cloud): ₹15-30 lakh annually
• Endpoint Detection and Response: ₹5-12 lakh annually
• Network monitoring tools: ₹8-15 lakh annually

Log Management:

• 180-day log retention storage: ₹5-10 lakh annually
• Log management platform: ₹3-8 lakh annually
• Backup and archival: ₹2-5 lakh annually

Incident Response:

• Managed SOC services: ₹10-20 lakh annually
• Incident response retainer: ₹5-12 lakh annually
• 24x7 escalation support: ₹3-8 lakh annually

Total Annual Cost: ₹56-130 lakh (₹0.56-1.3 crore)

Medium Organizations (200-2,000 employees)

Detection Infrastructure:

• Enterprise SIEM with SOAR: ₹50 lakh-1.5 crore annually
• Advanced threat detection: ₹20-60 lakh annually
• Security orchestration tools: ₹15-40 lakh annually

Log Management:

• Enterprise log infrastructure: ₹20-50 lakh annually
• Compliance reporting tools: ₹10-25 lakh annually
• Disaster recovery for logs: ₹8-20 lakh annually

Operations:

• Outsourced SOC with Indian presence: ₹40-80 lakh annually
• Internal security team augmentation: ₹25-60 lakh annually
• Compliance management: ₹10-30 lakh annually

Total Annual Cost: ₹1.98-4.7 crore

Large Organizations (2,000+ employees)

Detection Infrastructure:

• Enterprise SIEM platform: ₹1.5-4 crore annually
• Advanced analytics and AI: ₹80 lakh-2 crore annually
• Threat intelligence feeds: ₹30-80 lakh annually

Operations:

• Internal SOC (team + facilities): ₹2-5 crore annually
• 24x7 incident response team: ₹1.5-3 crore annually
• Compliance and audit support: ₹40-80 lakh annually

Infrastructure:

• Log storage and management: ₹50 lakh-1.5 crore annually
• Network and endpoint monitoring: ₹60 lakh-1.2 crore annually
• Backup and disaster recovery: ₹30-70 lakh annually

Total Annual Cost: ₹6.4-17.3 crore

These costs contrast sharply with non-compliance penalties. IT Act Section 43A provides for compensation up to ₹5 crore for data protection negligence. CERT-In can mandate expensive security audits, require immediate remediation, and in extreme cases, block organizational services. Reputational damage and customer loss often exceed direct penalty costs.

The business case: CERT-In compliance cost represents 0.5-2% of annual IT budget for most organizations. Non-compliance risk includes regulatory penalties, operational disruption, and reputation damage that typically exceed compliance investment by 5-10x.

30-Day CERT-In Compliance Quick-Start Playbook

Immediate compliance improvement requires systematic 30-day implementation focusing on highest-impact activities:

Week 1: Foundation and Registration

Day 1-2: PoC Registration

• Register designated Point of Contact at cert-in.org.in
• Verify contact details and 24x7 availability
• Establish backup contacts with mobile numbers
• Test CERT-In communication channels

Day 3-4: NTP Audit

• Inventory all systems requiring time synchronization
• Identify systems not synchronized to Indian NTP sources
• Plan NTP server configuration changes
• Document current time drift across infrastructure

Day 5-7: Log Source Inventory

• Catalog all log-generating systems and applications
• Map log retention periods against 180-day requirement
• Identify log sources missing or inadequately retained
• Calculate storage requirements for compliance

Week 2: Detection and Monitoring

Day 8-10: SIEM Coverage Assessment

• Evaluate current security monitoring capabilities
• Identify gaps in log ingestion and analysis
• Plan SIEM deployment or enhancement project
• Configure alerting for critical incident categories

Day 11-12: Threat Intelligence Integration

• Subscribe to CERT-In advisory feeds
• Configure NCIIPC alert monitoring
• Integrate threat intelligence with security tools
• Train security team on Indian threat landscape

Day 13-14: Detection Capability Testing

• Simulate attack scenarios for key incident categories
• Measure mean time to detection for critical threats
• Identify blind spots in monitoring coverage
• Document detection capability gaps

Week 3: Response and Reporting

Day 15-17: Incident Classification Training

• Train security team on 20 reportable incident categories
• Create quick-reference cards for incident classification
• Develop escalation decision trees
• Practice incident categorization with historical examples

Day 18-20: Report Template Creation

• Draft incident report templates for top 5 incident types
• Pre-populate standard organizational information
• Create secure submission procedures
• Test reporting process with mock incidents

Day 21: 24x7 Escalation Testing

• Verify escalation matrix contact information
• Test weekend and holiday escalation procedures
• Confirm decision authority for incident reporting
• Document escalation response times

Week 4: Governance and Documentation

Day 22-24: Policy Documentation

• Document all Week 1-3 implementation activities
• Create CERT-In compliance standard operating procedures
• Establish compliance monitoring and reporting procedures
• Develop compliance gap tracking mechanisms

Day 25-27: Compliance Testing

• Conduct end-to-end incident simulation exercise
• Measure time from detection to CERT-In reporting
• Identify remaining procedural gaps
• Document lessons learned and improvement actions

Day 28-30: Leadership Briefing

• Prepare board presentation on compliance status
• Document residual risks and budget requirements
• Plan quarterly compliance review schedule
• Establish annual mock incident exercise program

30-Day Deliverables:

• CERT-In PoC registered and verified
• Complete log source inventory with retention gaps identified
• NTP synchronization plan for all systems
• Incident response procedures for top 5 threat categories
• 24x7 escalation matrix tested and verified
• Compliance monitoring and reporting procedures
• Leadership briefing on compliance status and next steps

This playbook provides immediate compliance improvement while establishing foundation for comprehensive long-term compliance program.

SARC Perspective: Building Sustainable CERT-In Compliance

After supporting dozens of organizations through CERT-In compliance implementation, consistent patterns emerge in successful programs versus compliance theater.

The most critical success factor: treating CERT-In compliance as cybersecurity capability building, not regulatory checkbox ticking. Organizations approaching compliance as minimum viable reporting consistently fail during actual incidents. Those building detection, response, and governance capabilities achieve compliance while strengthening overall security posture.

Start with detection capabilities, not reporting procedures. The 6-hour reporting window assumes incident awareness. Organizations with 200+ day mean time to detection can't achieve meaningful compliance. Investment priority: SIEM deployment and tuning, endpoint detection, and network monitoring before incident response process optimization.

Second insight: cloud-first organizations face unique compliance challenges. Default cloud configurations rarely satisfy Indian regulatory requirements. Log retention, data residency, and incident response procedures require explicit Indian compliance configuration. Cloud shared responsibility models demand customer-side compliance management.

Third pattern: multi-regulator compliance creates optimization opportunities. Banks satisfying both CERT-In and RBI requirements through integrated programs achieve lower total cost than separate compliance initiatives. The marginal cost of multi-regulator compliance typically runs 20-30% of individual program costs.

Implementation sequence matters significantly. Organizations attempting comprehensive compliance transformation simultaneously across all five layers typically fail due to resource constraints and change management challenges. Successful implementations follow staged approach: detection first, then reporting, retention, response, and governance.

The governance insight: CERT-In compliance sustainability requires board-level commitment and budget allocation. Cybersecurity incidents are operational realities, not IT problems. Organizations treating cyber compliance as IT initiative rather than business risk management consistently underinvest in capabilities and fail during real incidents.

For immediate action: conduct 30-day quick-start implementation focusing on PoC registration, log inventory, and incident categorization training. These high-impact, low-cost activities provide immediate compliance improvement and foundation for comprehensive program development.

Long-term success requires treating CERT-In compliance as cybersecurity capability investment with compliance as beneficial outcome, not compliance as isolated regulatory requirement with minimal security value.

Frequently Asked Questions

Does the 6-hour rule apply to attempted attacks that were blocked? It depends on targeting. A generic malware email caught by your spam filter isn't reportable. A spear-phishing campaign specifically crafted for your organization — using your CEO's name, referencing internal projects — is reportable under Category 7 even if your email security blocked it. The threshold is targeted attack against your systems, not successful compromise. A DDoS attack mitigated by your CDN is reportable under Category 8 because it targeted your infrastructure. When in doubt, report — CERT-In prefers over-reporting to discovering unreported incidents during investigations.

What if we're a small company with no dedicated security team? CERT-In makes no size-based exemptions. A 15-person fintech faces identical obligations as SBI. Practical options: engage a managed security service provider (MSSP) with CERT-In reporting capability for ₹10-20 lakh annually, use cloud-native security tools (AWS GuardDuty, Azure Sentinel) for detection, and maintain pre-drafted incident report templates. The 30-day quick-start playbook in this guide is designed specifically for resource-constrained organizations. Most small companies can achieve baseline compliance for under ₹50 lakh annually.

Do cloud-hosted applications need separate CERT-In compliance? Yes. Cloud shared responsibility models mean your provider secures the infrastructure, but you're responsible for compliance configuration. Default cloud settings rarely satisfy Indian requirements — log retention defaults are typically 30-90 days (CERT-In requires 180), and logs may default to non-India regions. You must explicitly configure 180-day retention in Indian regions, enable all required log types, and maintain incident response procedures for cloud-hosted systems. Your cloud provider's SOC 2 certification doesn't satisfy your CERT-In obligations.

How does CERT-In compliance interact with our RBI/SEBI obligations? They operate in parallel but can be optimized together. A bank filing a 6-hour CERT-In report for a data breach must also notify RBI "immediately" and file a separate DPDP breach notification. The same incident triggers three regulatory reports in different formats. The optimization: build one incident response workflow that generates all required reports simultaneously. Organizations building for the most demanding intersection — typically CERT-In's 6-hour window plus SEBI's 5-year log retention — automatically satisfy other regulators. One robust program mapped to four frameworks costs 20-30% of maintaining separate compliance programs.

What happens if we miss the 6-hour reporting window? CERT-In treats late reporting seriously but considers context. A report filed at hour 8 with reasonable justification (complex incident requiring initial triage) faces different consequences than deliberate non-reporting discovered during investigation months later. Penalties fall under IT Act 2000 provisions — Section 43A provides for compensation up to ₹5 crore, and Section 66 covers criminal provisions for dishonest concealment. CERT-In can also mandate security audits at the organization's expense and issue binding remediation directions. The practical advice: file a preliminary report within 6 hours even if incomplete, then follow up with detailed analysis. Late reporting is penalized; preliminary reporting with follow-up is accepted practice.

Are international subsidiaries of Indian companies covered? CERT-In Directions apply to organizations operating computer systems "in India." An Indian company's subsidiary operating servers in Singapore isn't directly covered by CERT-In for those Singapore systems. However, if those overseas systems process data of Indian users or connect to Indian infrastructure, the Indian parent's reporting obligations may be triggered. The safe approach: include overseas systems that touch Indian data or networks in your CERT-In compliance scope. Many Indian enterprises maintain global SOC operations that detect incidents across geographies — any incident affecting Indian operations or data falls under CERT-In jurisdiction regardless of where the attack originated.

Do we need a CERT-In empanelled auditor for compliance? CERT-In empanelment is required for organizations conducting security audits on behalf of CERT-In or for regulatory compliance audits mandated by CERT-In. For voluntary compliance assessments, any qualified cybersecurity auditor can evaluate your posture. However, using a CERT-In empanelled auditor provides regulatory credibility and ensures audit methodology aligns with CERT-In expectations. For organizations in regulated sectors (banking, insurance, listed companies), sector regulators like RBI and SEBI require audits by empanelled or approved auditors — check your sector-specific requirements. Can we outsource CERT-In compliance to a managed security provider? You can outsource detection, monitoring, and log management — but you cannot outsource accountability. The designated PoC must be your employee, incident reporting decisions require your authorization, and CERT-In coordinates with your organization, not your vendor. Effective outsourcing model: MSSP handles 24x7 monitoring and detection (Layer 1), escalates to your internal team for classification and reporting decisions (Layer 2), and manages log infrastructure (Layer 3). Your organization retains incident response authority, CERT-In relationship, and governance responsibilities. Ensure your MSSP contract includes CERT-In-specific SLAs: detection-to-escalation under 30 minutes, log retention compliance guarantees, and Indian data residency requirements.

What This Means for Your Organization The gap between CERT-In compliance intent and operational reality is where regulatory risk lives. Most Indian organizations have cybersecurity policies. Few have tested whether they can actually detect an incident, classify it correctly, and file a compliant report within 6 hours on a Saturday night. Start with the honest question: if a ransomware attack hit your systems tonight, could your team detect it within an hour, classify it under the correct CERT-In category, and file a preliminary report before morning? If the answer is anything other than "yes, and we've tested it," you have compliance gaps that need immediate attention.

The 30-day quick-start playbook above gives you the fastest path to baseline compliance. For organizations needing comprehensive implementation — multi-regulator mapping, SIEM deployment, incident response architecture, and board-level cyber governance, SARC's Cybersecurity Practice has built CERT-In compliance programs for enterprises across BFSI, manufacturing, and government sectors.

Request SARC's CERT-In Readiness Assessment, a 40-point diagnostic covering detection maturity, reporting capability, log compliance, response readiness, and governance gaps, mapped to your specific sector regulator requirements. Meet our Cybersecurity team.