Month: August 2026

Firewall Ruleset Review: What Your Rules Are Really Allowing

Posted on by admin

Your firewall enforces whatever its rules permit — no exceptions, no judgment calls. A firewall ruleset review is a line-by-line audit of allow, deny, and NAT entries across your configuration, hunting for overly broad permissions, duplicate rules, shadowed entries, and compliance gaps. Skip this review, and you carry forward risk baked into rules someone wrote years ago for servers and segments that no longer exist. If your last full rule base review was more than six months back, your firewall is likely enforcing policies built for a network topology and regulatory landscape that have both moved on.

What Gets Examined in a Firewall Ruleset Review

This goes well beyond checking whether the firewall is powered on. A proper ruleset review digs into rule sequencing and logic — spotting shadowed rules that sit idle because a broader rule higher up already matches the traffic. It picks out any-to-any permits and wide-open entries that break least privilege. Logging configurations get scrutinized too: if critical permit and deny rules are not writing logs, your SOC is flying blind when something goes wrong. NAT and PAT setups are tested for accidental exposure of internal hosts. And every rule gets checked against its documented business justification — an unexplained rule is an incident in waiting.

Rule lifecycle matters just as much. When was each rule added, who signed off, and is there an expiry date? Rules tied to retired servers, departed staff, or wrapped-up projects turn up in nearly every assessment.

Compliance Frameworks That Mandate It

For regulated industries in India and internationally, firewall ruleset reviews sit squarely inside mandatory audit requirements.

Under PCI DSS 4.0.1, which is now fully in effect, Requirement 1 calls for a review of firewall and router rule sets no less than once every six months. Each permitted service, protocol, and port needs a documented business reason behind it. ISO 27001:2022 tackles this through Annex A Controls 8.20 and 8.21 — network security and security of network services — both of which call for regular validation of access controls at the network layer. Over at NIST, the Cybersecurity Framework places firewall rule governance under the Protect function, specifically PR.AC for access control and PR.PT for protective technology. In India, RBI’s Cybersecurity Framework for banks and SEBI’s CSCRF for market intermediaries each require periodic checks on network security controls, firewalls included. CERT-In’s cybersecurity directives add another layer of expectation: firewall policies must be reviewed, documented, and kept current.

A neglected rule base is not merely a technical weakness. It is an audit finding — one that can stall a certification, invite regulatory follow-up, or widen your liability after a breach.

Findings That Show Up Again and Again

Some issues appear in almost every assessment. Rules configured with “any” as the source or service make up the bulk of findings — wide-open doors nobody questioned. Orphaned rules linked to decommissioned systems stay active, quietly expanding the attack surface. Logging turned off on key permit rules means a breach through a legitimate path leaves little forensic evidence. Poor naming conventions slow down audits, and without documented change management, nobody can say why a rule exists or when it was last validated.

Running a Firewall Ruleset Review — Step by Step

Start with a complete rule export paired with a current topology map, so the review team knows what the firewall is actually protecting. Walk through each rule against the documented network architecture and active business requirements. Sort findings into severity bands: critical for any-to-any permits on production segments, high where business justification is missing, medium for logging gaps, low for naming and documentation shortfalls. Pull it all together into a remediation report — prioritized, with a realistic cleanup timeline attached. Then lock in a recurring review schedule, at least once every six months, synced with your compliance calendar so it does not slip.

Where QRC Fits In

QRC Solutions is a CERT-In empanelled firm that carries out firewall ruleset reviews under its network and configuration review practice. Findings are mapped straight to PCI DSS, ISO 27001, RBI, SEBI CSCRF, and IRDAI requirements — one report that works for both your security operations team and your auditors. To book a firewall ruleset review or ask for a sample report, write to  connect@qrcsolutionz.com

CEA Cyber Security Regulations 2026: Compliance Guide

Posted on by admin

The Central Electricity Authority (Cyber Security in Power Sector) Regulations, 2026 create an auditable cyber security framework for India’s power ecosystem. Most provisions take effect on 1 April 2027 and cover governance, critical IT and operational technology, incident reporting, data residency, vendor security, audits and evidence retention. Six provisions will commence later through separate CEA orders. Covered organisations should begin with applicability, asset classification, gap assessment and accountable remediation rather than treating compliance as a policy exercise.

Who must comply with the CEA Cyber Security Regulations 2026?

The regulations apply to entities that own, operate or manage OT infrastructure connected with the interconnected power system, together with IT infrastructure physically or logically connected to it. Generating companies, captive plants and organisations operating energy storage systems are covered where installed capacity is 50 MW or more. Power exchanges and over-the-counter platforms are covered with stated exceptions, while vendors must meet Regulations 11 and 12 where applicable. Entities below 50 MW are encouraged to adopt CERT-In’s 15 Elemental Cyber Defense Controls.

What are the main compliance requirements?

Covered entities must appoint a senior-management CISO and Alternate CISO, define reporting lines and maintain board-approved cyber security governance. They must identify cyber assets, classify critical IT and OT systems, document network architecture and maintain a Cyber Risk Assessment and Mitigation Plan.  The technical focus is equally clear. OT systems should be physically isolated from the internet and IT networks. Where an IT-OT connection is necessary, hardened logical separation, documented risk assessment, formal approval, continuous monitoring and retained logs are required. Remote access to critical systems must be limited, approved and protected through measures including least privilege, multi-factor authentication and geo-fencing.

Sensitive information, including cloud-hosted and historical data, must remain encrypted, protected and resident in India. Critical-system backups must be current, separately maintained and restoration-tested. Entities must also establish incident response, cyber crisis management, supply-chain security, vulnerability management and evidence-retention processes.

What deadlines should organisations track?

  • Cyber security incidents: report to CSIRT-Power and CERT-In within six hours.
  • Cyber sabotage affecting critical systems: report within 24 hours once concluded as sabotage.
  • New or replaced critical systems: provide required details to CSIRT-Power within 30 days.
  • Critical Information Infrastructure: approach the Appropriate Government within 60 days of identification.
  • Audit findings: address critical and high risks within one month medium and low risks within three months.

A comprehensive cyber security audit is required every financial year, with a nine-to-fifteen-month gap between consecutive audits. The auditor must issue the report within six weeks of commencement, and the closure report is due within six months. A separate self-audit is also required annually.

A practical readiness roadmap

Start by documenting applicability across legal entities, facilities, OT environments, connected IT systems and vendors. Build a clause-by-clause register linking every requirement to a control owner, implementation status and evidence source. Review network separation, remote access, logging, monitoring, time synchronisation, backups, data residency and vendor contracts.  Next, test operational readiness. Run incident-response and cyber-crisis exercises, validate the six-hour escalation path, test backup restoration and sample evidence retrieval. Establish an audit calendar that tracks assessment, remediation and closure deadlines. Boards should receive regular reporting on readiness, exceptions, residual risk and future CEA or CSIRT-Power directions.

Frequently asked questions

  1. When do the regulations take effect?
    Most provisions take effect on 1 April 2027. Regulations 5(9), 5(24), 5(33), 5(39), 6(2) and 6(7) will commence on dates notified separately.
  2. Is ISO/IEC 27001 certification mandatory?
    Regulation 5(24) requires ISO/IEC 27001 or a Technical Criteria Certificate covering critical systems, but its commencement depends on a separate CEA order.
  3. What should organisations do first?
    Complete an applicability assessment, confirm CISO accountability, inventory critical systems, assess gaps and create a clearly evidence-led implementation plan.


Prepare before the compliance clock starts

The CEA Cyber Security Regulations 2026 require coordinated action across leadership, IT, OT, engineering, procurement, legal, business continuity, internal audit and vendors. QRC Assurance & Solutions supports power-sector entities through regulatory readiness assessments, IT-OT security reviews, VAPT, CERT-In empanelled cyber security audits, evidence validation and remediation tracking. To discuss your readiness programme, contact connect@qrcsolutionz.com or visit qrcsolutionz.com.

Read the full article here :  Central Electricity Authority – Cyber Security Regulations notification

Disclaimer: This article is an executive interpretation for awareness and planning and is not legal advice. The notified Gazette and subsequent competent-authority directions prevail.

Incident Response Planning for Regulated Entities in India

Posted on by admin
Every regulated entity has an incident response plan. It sits in a policy document, usually last updated during the previous audit cycle, and describes a theoretical process for handling security incidents. The problem is that most plans are designed to pass an audit, not to handle an incident. When a real security event occurs, the plan fails for predictable reasons. The escalation contacts are outdated. The classification criteria are too vague to apply to the actual incident. The communication templates do not cover the specific regulatory reporting requirements. The technical team has never practiced the containment procedures. The legal team has not reviewed the breach notification language. The regulatory reporting timelines are documented but the process for gathering the required information within those timelines has never been tested. The organizations that respond effectively to incidents are those that treat the incident response plan as an operational procedure that is practiced, tested, and updated regularly – not a compliance document that is reviewed annually. If your team’s first encounter with the incident response plan is during an actual incident, your response will be improvised regardless of what the plan says.

Multi-Regulatory Incident Response Requirements
Indian regulated entities face incident response obligations from multiple regulators, each with specific requirements. RBI requires banks, NBFCs, and PSOs to report cyber incidents to RBI and CERT-In within specified timelines. The reporting includes the nature of the incident, systems affected, estimated impact, containment actions, and remediation plans. For RBI-regulated entities, the cyber crisis management plan is a specific requirement separate from the general incident response plan. SEBI’s CSCRF requires regulated entities to report cyber incidents to SEBI and CERT-In within 6 hours of detection. The reporting framework includes a prescribed format and specific categories of reportable incidents. SEBI also expects post-incident analysis and lessons learned reports within 14 days. DPDP Act requires notification to the Data Protection Board and affected data principals when a personal data breach occurs. The notification must include the nature of the breach, the categories of personal data affected, and the measures the data principal can take to protect themselves. The timeline for notification is prescribed in the DPDP Rules. PCI DSS Requirement 12.10 mandates an incident response plan that addresses specific elements – roles and responsibilities, communication and contact strategies, media handling, legal analysis, containment and mitigation, business recovery, and lessons learned. PCI forensic investigation may be required for breaches involving cardholder data. Building a single incident response framework that satisfies all these requirements simultaneously requires careful mapping and integration.

Building an Integrated Incident Response Framework
Start with incident classification. Define categories that map across all applicable regulations – data breach involving personal data, data breach involving cardholder data, system compromise, denial of service, malware infection, insider threat, and third-party breach. For each category, document which regulatory notifications are required, the reporting timeline for each regulator, the information required in each notification, and the internal escalation path. Build a notification decision matrix. When an incident is detected, the response team needs to quickly determine which notifications are required. A compromise of a payment system that also processes personal data triggers PCI DSS forensic investigation requirements, RBI incident reporting, CERT-In reporting, and DPDP breach notification – four separate notification processes with different timelines and different information requirements. Pre-draft your notification templates. For each regulator, prepare notification templates that include the required fields with placeholders for incident-specific information. During an actual incident, your team should be filling in the specifics, not figuring out the reporting format. Have legal review these templates in advance. Establish clear roles and responsibilities. Designate an incident commander who owns the overall response. Assign specific individuals to technical containment, forensic evidence preservation, regulatory notification, internal communication, external communication, and legal coordination. Each role should have a primary and backup individual, with contact information verified quarterly.
The First 24 Hours: A Response Playbook
Hour 0-1: Detection and initial triage. When a potential incident is detected – through SOC monitoring, user report, third-party notification, or automated alert – the on-call security analyst conducts initial triage. Is this a true positive? What systems are affected? Is the incident ongoing? What is the initial severity classification? Notify the incident commander. Hour 1-4: Containment and assessment. The incident commander activates the response team based on the incident classification. Technical team implements immediate containment – isolating affected systems, blocking malicious IPs, disabling compromised accounts – while preserving forensic evidence. Parallel track: begin gathering information required for regulatory notifications. For SEBI-regulated entities, the 6-hour notification clock is running. Hour 4-6: Regulatory notification preparation. Based on the incident assessment, determine which regulatory notifications are required. Complete the notification templates with available information – you do not need to wait for a complete picture before notifying. Initial notifications are expected to be preliminary, with follow-up reports providing additional detail. Submit notifications to the relevant regulators within their prescribed timelines. Hour 6-24: Deep investigation and remediation. With containment in place and initial notifications submitted, the focus shifts to understanding the full scope of the incident, identifying the root cause, assessing the extent of data exposure or system compromise, and planning remediation. Continue updating regulators as new information becomes available. Engage external forensic investigators if the incident involves cardholder data or if the scope exceeds your internal team’s capability.

Testing Your Incident Response Through Tabletop Exercises
The single most effective way to improve your incident response capability is to practice it. Tabletop exercises simulate security incidents and walk your response team through the process without the pressure of a real event. Conduct these exercises quarterly, rotating through different incident scenarios. Design scenarios that test specific response capabilities. A ransomware scenario tests your backup and recovery procedures, communication with law enforcement, and decision-making around ransom payment. A data breach scenario tests your forensic investigation capability, regulatory notification process, and customer communication. A third-party breach scenario tests your vendor notification procedures and supply chain risk assessment. A DDoS scenario tests your business continuity procedures and customer communication. Each tabletop exercise should involve the full response team – technical, legal, compliance, communications, and executive leadership. The exercise should follow the timeline pressure of a real incident, including simulated regulatory notification deadlines. After each exercise, conduct a structured debrief identifying what worked, what failed, and what needs to change in the incident response plan. Document the findings and track the implementation of improvements. When a regulator asks whether your incident response plan has been tested, the exercise records, debrief reports, and improvement tracking provide concrete evidence. This is significantly more valuable than simply stating that the plan was reviewed annually.
Q: What is the incident reporting timeline for CERT-In?
A: CERT-In requires reporting of cyber security incidents within 6 hours of the entity becoming aware of the incident. This applies to all entities, not just regulated financial institutions.
Q: Do we need a PCI forensic investigator for every payment data breach?
A: Not always, but your payment brand or acquirer may require a PFI investigation for breaches involving cardholder data. Engage your QSA and acquiring bank immediately when a potential cardholder data breach is identified.
Q: How often should we conduct incident response drills?
A: Quarterly tabletop exercises with different scenarios. Additionally, conduct at least one full simulation exercise annually that tests your complete response capability including regulatory notification.
QRC helps regulated entities build and test incident response programs that satisfy RBI, SEBI, PCI DSS, and DPDP requirements. Contact us for an incident response readiness assessment.