Kavita Rao’s Zero Trust Rollout: An ISE Segmentation Fix Guide for Fast-Growing Enterprises

Kavita Rao, the CISO of a rapidly expanding Indian tech company, reached a breaking point the day her team traced a minor HR system compromise to a development VM three VLANs away. Nothing catastrophic happened. But it was a warning. A flat network had turned a routine misconfiguration into a potential blast radius. Segmentation had been on her roadmap for years. Now it was urgent. 

This is the guide that emerged from that journey: a practical view of how ISE-based segmentation is designed, deployed, and fixed when real organisations, not idealised architectures, face sprawl, device diversity, and constant change. 

The Problem Kavita Inherited 

Kavita’s organisation resembled a typical fast-growing Indian ITeS firm: high analyst churn, project-based access, a mix of managed and unmanaged devices, and dozens of client-specific data environments all accessed through the same broad network. VLANs originally created for 200 users now carried more than a thousand. Contractors and interns connected through personal laptops. IoT devices sat on the same broadcast domains as production endpoints. Project VMs, developer sandboxes, and customer environments shared east-west pathways. 

ISE was deployed, but segmentation never left the design deck. Authentication worked. Authorisation did not. The network knew who users were but did not act on that knowledge. Kavita saw the result in the HR-system incident: lateral movement was possible because nothing segmented risk from risk. 

The ISE Segmentation Reference Model 

Fast-growing tech and analytics organisations need segmentation that reflects how they operate, not how traditional campuses are designed. Kavita’s reference model landed on six zones. 

1. User Zone for employees and analysts. 
2. Contractor Zone for external partners, BPO staff, and project-based workers. 
3. Project Zone for client-specific datasets and compute clusters. 
4. Dev/Lab Zone for engineers, QA, and pre-production systems. 
5. IoT/Device Zone for sensors, cameras, and meeting-room devices. 
6. Privileged Zone for admins and elevated roles. 

Each zone represented a trust boundary. Movement between zones required an explicit policy, not implicit access based on VLAN membership. 

Where Segmentation Breaks, and How Kavita Fixed It 

ISE segmentation fails most often in environments that grow faster than their controls. Identity sources become inconsistent. AD groups accumulate outdated roles. Service accounts get mislabelled. Switches run mixed software versions. IoT devices lack classification. Firewall rules contain years of exceptions no one remembers creating. 

Kavita found all of this. Before designing new segmentation, identity stores were cleaned, devices profiled, and zone candidates mapped based on how people worked and how data moved. Her implementation followed ten structured steps: 

1. Stabilise identity sources. Rationalise AD groups, separate contractors, and verify ownership of service accounts. 
2. Profile devices. Use ISE posture to distinguish managed laptops, BYOD endpoints, and IoT devices. 
3. Design trust zones. Base the model on user behaviour and risk, not legacy VLAN topology. 
4. Map identity attributes to zones. Define precise access boundaries for each role. 
5. Validate enforcement gradually. Start with one floor, expand to one building, then campus-wide. 
6. Test downloadable ACLs. Ensure consistency across switch models and software versions. 
7. Handle legacy systems. Create controlled exceptions instead of broad access. 
8. Extend segmentation to wireless. Apply consistent policy across wired and wireless sessions. 
9. Reduce policy exceptions. Align analysts, developers, and business teams with least-privilege access. 
10. Operationalise segmentation. Establish periodic reviews so the model scales with organisational growth. 

The ISE Segmentation Architecture That Finally Worked 

The earlier ten-step rollout already defined the structure. The corresponding enforcement actions aligned with it: 

1. Identity sources aligned. AD groups rationalised and contractor roles isolated. 
2. Devices profiled. Managed, unmanaged, and IoT endpoints distinguished through posture checks. 
3. Zones implemented. Trust boundaries enforced as designed, independent of VLAN layout. 
4. Role-to-zone mapping applied. Precise permissions tied directly to identity attributes. 
5. Progressive enforcement rolled out. Validation started on a single floor, scaled campus-wide. 
6. DACLs deployed consistently. Tested and applied across switch models and code versions. 
7. Legacy systems isolated. Controlled exceptions added without broadening access. 
8. Wireless integrated. Policies remained consistent across wired and wireless sessions. 
9. Exceptions reduced. Teams aligned around least-privilege access across environments. 
10. Operations formalised. Periodic reviews ensured segmentation evolved with organisational growth. 

What the Architecture Looked Like 

ISE became the identity and policy authority. Switches enforced DACLs. Wireless controllers applied role-based access. Firewalls validated east-west movement between critical zones. IoT devices landed in tightly restricted segments. Developers gained controlled access to project environments with elevated logging and monitoring. 

The architecture was not theoretical. It matched how work happened inside Kavita’s organisation: analysts moving between client datasets, engineers testing builds, contractors joining mid-cycle, and project clusters spinning up and down. 

Why Indian ITeS Enterprises Cannot Delay Segmentation 

ITeS firms deal with client data, analyst churn, project-based access, and pressure to pass strict enterprise audits. A flat network increases the blast radius of every minor compromise. Segmentation reduces this risk and makes incidents easier to contain. 

CIO Decision Framework 

For a CIO evaluating the shift, four questions determine direction. 

1. Do cloud applications handle core workflows? If yes, identity-driven segmentation becomes essential because SaaS traffic bypasses traditional network controls. 
2. Does the workforce include contractors, analysts, or BYOD? If yes, device posture must be enforced, and OTP-style controls will not scale. 
3. Does the environment contain client-specific data or compute clusters? If yes, segmentation is required to isolate workloads and meet audit expectations. 
4. Does the organisation face frequent audits or enterprise client reviews? If yes, segmentation provides measurable evidence of access control. 

CIOs who answer yes to these conditions find segmentation less an optional upgrade and more a structural requirement. 

Your Next Steps 

Kavita’s experience is common. Segmentation is not a theory problem. It is an identity and enforcement alignment problem. Organisations that fix it early avoid blast-radius failures later. 

Proactive works with security and network teams to design and deploy ISE-based segmentation that fits fast-growing ITeS environments. If you want a rollout plan that holds up under audit and scales with growth, our team can help.