Inside SailPoint, the company’s own IT environment runs on the same identity security platform it offers customers. As Chief Information Officer, Sree Kancharla oversees that implementation while also participating in the company’s customer zero program.
In this interview, Kancharla addresses the limits of compliance-driven identity programs, the operational demands of managing machine identities, and the organisational challenges involved in reducing silos across identity, infrastructure, and security teams.
What happens when identity programs prioritise compliance over business enablement?
Based on our experience, the consequence is twofold: a failure to generate strategic business value and constrained operational efficiency.
If a program focuses only on maintaining compliance, it remains manual and reactive. It fails to leverage automation, and it misses the opportunity to integrate security into broader digital transformation efforts. Ultimately, that narrowly focused program risks becoming a cost centre rather than a function that delivers efficiencies across the entire value chain.
How can enterprises balance access speed and control as machine identities grow?
The future requires moving away from traditional standing privileges to an adaptive, just-in-time access model. To balance speed and control, enterprises should actively work towards an identity system where access privileges are provided on a moment-to-moment basis. This ensures each identity has a clearly defined role that entitles it to perform specific functions, and that the system removes those entitlements once the task is complete. Access is therefore provisioned rapidly when needed and revoked immediately afterwards, maintaining control.
By adopting a just-in-time access model, enterprises can better balance access speed with control, reduce unnecessary exposure, and maintain tighter oversight of machine identities.
What did SailPoint learn from implementing its identity tools internally?
When we implemented our tools internally as a customer zero, the objective was to increase automation and improve efficiency in managing our human, non-human, machine, and agent identities, while maintaining compliance and strengthening security controls. We also aimed to reduce bottlenecks in provisioning and de-provisioning, and to decrease manual audit and compliance work. The primary challenges we encountered, and what they revealed about customer needs, centred on data foundations and the ability to scale.
The first challenge was data hygiene. Data quality is fundamental to identity security and is frequently cited by customers as a major pain point. We found that roles, entitlements, and access permissions are only as reliable as the data supporting them. Establishing greater visibility across target systems highlighted aspects we hadn’t been aware of in our environment. This reinforced the need for reliable, high-quality data to prevent overprovisioning and ensure automation can operate at scale with integrity. We prioritised improving data within critical application integrations, including Active Directory and Workday, to establish clearer parameters.
The next challenge was securing cooperation from the internal owners of key applications. To overcome poor data visibility, we worked closely with application owners to ensure data was accurate and actionable. This collaboration enabled the development of a more structured access model and improved request handling through our self-service access request centre.
Then came rapid scaling and fragmentation. We expanded from a core set of connected systems to more than 100 directly connected systems, and consolidated dozens of additional applications under our Active Directory connector.
What was the hardest part of breaking down identity, infrastructure, and security silos?
The hardest part of unifying identity, infrastructure, and security was establishing strong data hygiene practices. You cannot break down silos if the data being exchanged across those divisions is unreliable or inconsistent. Roles, entitlements, and access permissions are ineffectual if the data they are built on is poor.
We addressed this challenge through two components. The first was top-down executive buy-in. Meaningful improvements to identity security require clear support from company leadership. Our executive leadership aligned early, which helped accelerate the program, communicate its objectives across business units, and establish internal partnerships. Without that top-down support, it would have been difficult to achieve the outcomes we did.
The second was expanding connectivity and integration, moving from a handful of connected systems to more than 100 to reduce fragmentation in identity processes. Where direct integration was not possible, we relied on workflows and REST APIs to extend coverage and maintain visibility into identity access and activity across critical internal systems.
How is the CIO role in an identity security company different from a typical enterprise CIO?
The fundamental difference lies in the positioning of identity security within the C-suite and the CIO’s accountability to the product itself. The role includes running internal customer zero programs, adopting newly released features, and providing real-time feedback to R&D teams to inform product development.
First, executive alignment around identity security is embedded within the organisation. Executives understand the product, the underlying processes, and the strategic importance of identity security. In many other enterprises, CIOs must first articulate that business value and secure executive backing before advancing identity initiatives.
Another key difference is the customer zero mandate. In this role, the CIO is responsible for implementing and validating the company’s own platform internally. This creates a direct feedback loop between internal operations and product development, with real-world implementation experience informing future enhancements. A typical enterprise CIO does not usually have direct influence over the product roadmap of the technologies they deploy.
In essence, while most enterprise CIOs focus on aligning technology with business priorities, the CIO of an identity security company also operates as an internal product stakeholder, bridging operations, security, and product development.
