The Cloud Provider’s Blueprint: Navigating Data Localization and DPDP Compliance in India

For Cloud Service Providers (CSPs) operating in India, the financial services ecosystem has shifted. The days when cloud architecture was evaluated purely on uptime, compute pricing, and network latency are over. Today, data governance is the primary architectural driver.

With the framework of the Digital Personal Data Protection (DPDP) Act taking firm hold alongside its operationalized Rules, the compliance environment has entered a new phase. Simultaneously, the Reserve Bank of India (RBI) has doubled down on its digital sovereignty initiatives, explicitly seen in the strict compliance deadlines for digital lending guidelines and updated Master Directions on IT Governance.

This regulatory intersection transforms the role of a CSP. Cloud providers are no longer just passive background utility vendors; they have become active, co-regulatory compliance partners. If your cloud platform hosts workloads for Indian banks, non-banking financial companies (NBFCs), fintech platforms, payment gateways, or insurance firms, you are directly bound by a complex web of localization mandates.

The Dual-Regulator Reality: The Interaction of DPDP and Sectoral Mandates

To build or maintain a compliant financial cloud infrastructure in India, one must first understand the relationship between general privacy legislation and sector-specific financial rules.

The DPDP Act adopts a fundamentally business-friendly, "permissive by default" or "negative list" stance toward international data transfers (Section 16). In theory, personal data can flow across international borders unless the Central Government explicitly places a country or territory on its blacklist.

However, for financial data, this flexibility disappears. The DPDP Act contains a critical conflict clause: if any pre-existing or sectoral regulation imposes stricter data localization requirements, those stricter requirements override the general law. The RBI, the Securities and Exchange Board of India (SEBI), and the Insurance Regulatory and Development Authority of India (IRDAI) enforce absolute localization. For instance, the RBI’s mandate on the Storage of Payment System Data and its strict guidelines for digital lending require financial personal data, transaction records, and credit assessments to be anchored inside India.

For a CSP, this means you cannot rely on the general cross-border allowances of the DPDP Act when handling financial customer data. You must design and deliver an infrastructure that respects the strict boundary fences erected by India's financial regulators.

1. Anchoring Infrastructure: Deep Dive into India-Only Data Residency

The most immediate obligation for any CSP hosting financial workloads is ensuring absolute data residency within the geographic borders of India. This is rarely as simple as checking a box during resource provisioning. It requires a granular review of how data moves across the cloud environment.

Production, Staging, and Microservices

Every component of a financial application must reside locally. This includes not just the primary SQL/NoSQL databases, but also caching layers (like Redis or Memcached clusters), application message queues (such as Kafka or RabbitMQ), and staging or testing environments. A common point of failure occurs when a bank’s production environment is hosted in an India-based cloud region, but its analytics, staging, or QA pipelines pull data into an overseas region. Under current guidelines, this is a severe compliance violation.

The Disaster Recovery (DR) and Cold Storage Trap

 
High availability architectures typically dictate that DR sites be geographically separated from primary regions to survive localized natural disasters. For global CSPs, the instinct might be to replicate an active Mumbai region workload to an offshore region like Singapore or Dubai.

For Indian financial data, this is legally prohibited. Your architecture must offer multi-region or multi-availability-zone topologies entirely within India (e.g., pairing a Mumbai primary region with a Hyderabad or Pune DR region). This restriction applies equally to cold backups, long-term archival storage (like glacier vaults), and machine learning training datasets derived from customer profiles.

Managing Cross-Border Legs and the 24-Hour Purge Rule

The RBI does allow for a temporary exception when a transaction has an explicit international component—such as an Indian resident making a purchase from a foreign merchant or cross-border remittance. In these scenarios, the data may be transmitted and processed outside India.

However, the regulatory clock ticks fast. The RBI Master Directions dictate that the complete end-to-end data must be brought back to local storage, and any copies or traces residing on foreign servers must be permanently deleted within 24 hours.

As a CSP, your network architecture and data pipelines must feature automated, time-bound orchestration tools that guarantee the complete, unrecoverable purging of transient data from foreign edge locations or intermediate nodes inside that strict 24-hour window.

2. Becoming a "Processor-Ready" Partner Under the DPDP Rules

The DPDP Act draws a sharp legal line between the Data Fiduciary (the financial institution determining the purpose of data collection) and the Data Processor (the entity processing data on behalf of the Fiduciary—the CSP).

Section 8(2) of the Act stipulates that a Data Fiduciary can only engage a Data Processor under a valid, legally binding contract—a Data Processing Agreement (DPA). Because the DPDP Act introduces vicarious liability—meaning the financial institution remains legally liable for any privacy failures caused by its vendors—banks and fintechs will enforce rigorous terms down to their CSPs.

Enforcing Purpose Limitation at the Cloud Layer

DPAs must explicitly state the exact scope, duration, and purpose of data processing. For a CSP, this means your platform terms must reassure clients that you will not use their hosted data for any secondary purposes.

Crucially, this prevents cloud providers from utilizing customer data transcripts, financial behavior patterns, or document uploads to train their own internal AI models, LLMs, or optimization algorithms without distinct, explicit authorization.

Architecting for Rule 8: The Erasure and Retention Paradox

The DPDP Rules introduce specific operational challenges regarding data lifecycle management, particularly under Rule 8. Under the privacy framework, when a consumer withdraws consent or the underlying commercial purpose is completed, the Data Fiduciary must erase the data. This requires CSPs to provide erasure-propagation capabilities. When a bank triggers a deletion API, that command must reliably cascade through:

• Block storage volumes and object storage buckets.
• Ephemeral caches and serverless execution logs.
• Read-replicas, snapshots, and immutable backup chains.

However, Rule 8 introduces a counter-requirement: CSPs and Fiduciaries must retain processing logs, system traffic data, and access histories for a minimum of one year from the date of processing to facilitate breach investigations and legal defense.

Your cloud platform must therefore decouple customer data from infrastructure telemetry. While the individual’s personal data must be cleanly deleted, the underlying security, network, and access logs must be safely archived in a localized, tamper-evident repository for at least 12 months.

3. Cryptographic Isolation and Multi-Tenancy Governance

Public cloud infrastructure runs on multi-tenancy—the sharing of physical compute, storage, and network hardware across thousands of disparate customers. For risk-averse financial regulators, multi-tenancy represents a potential attack surface where data could leak across logical boundaries.

To host regulated entities safely, CSPs must implement robust data isolation models.

Advanced Cryptographic Separation (BYOK & HYOK)

Logical separation via software-defined networking (SDN) or hypervisor controls is no longer sufficient on its own. Financial enterprises now demand strict cryptographic isolation. CSPs must provide comprehensive Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK) infrastructures.

By integrating hardware security modules (HSMs) situated within Indian borders, banks can ensure that even if a cloud administrator or a rogue sub-processor accesses the raw storage blocks, the data remains unreadable. If the client holds the master keys externally, the CSP cannot decrypt the underlying financial data under any circumstance.

Tokenization Pipelines at the Edge

For entities processing credit card and debit card transactions, the RBI mandates strict card-on-file tokenization rules. CSPs must offer specialized, compliant edge-computing nodes inside India that intercept raw cardholder data at the point of ingestion, replace it with a secure token, and isolate the vault containing the actual card mapping in a highly restricted, ring-fenced database environment.

4. The 6-Hour Crucible: Incident Response and Forensic Telemetry

When a cybersecurity incident strikes a financial institution, the regulatory pressure intensifies. The RBI’s Master Directions on IT Governance mandate an aggressive timeline: regulated entities must report any cyber incident to the regulator within 6 hours of discovery. Concurrently, Rule 7 of the DPDP framework demands swift notification to both the Data Protection Board of India (DPBI) and affected individuals without undue delay.

Because a financial institution’s application runs on your cloud infrastructure, they cannot meet this 6-hour window unless your internal security operations are fully aligned with theirs.

Real-Time Forensic Provisioning

When a potential breach is flagged, the client's CISO team needs immediate access to system telemetry. CSPs must provide automated "Incident Report Packs" that deliver:

 

• Granular cloud audit trails showing exactly who accessed which object storage keys or database records.
• NetFlow logs indicating whether unauthorized data exfiltration occurred across external internet gateways.
• Snapshot capabilities to freeze compromised virtual machines or container instances for offline forensic analysis.

If your cloud support relies on a standard multi-day ticketing loop to extract and deliver network or access logs, you will directly cause your client to violate the 6-hour regulatory window. This exposure can lead to severe contractual liabilities and significant financial penalties.

5. Sub-Processor Accountability and Supply Chain Cascading

Modern hyper-scale clouds do not operate in a vacuum. They rely on an ecosystem of specialized sub-processors, third-party software marketplace vendors, and global engineering networks for continuous maintenance. However, under Section 8(1) of the DPDP Act, accountability cannot be offloaded. The primary Data Fiduciary remains liable, meaning they will scrutinize your entire supply chain.

Restricting Global Support Engineering Access

A major point of vulnerability for international CSPs is the "Follow-the-Sun" support model. If a database cluster in Mumbai experiences an outage at 2:00 AM IST, the ticket might automatically route to an on-call site reliability engineer (SRE) based in Europe or the United States.

If that foreign engineer accesses a live production environment containing unencrypted personal financial details, a cross-border data transfer has technically occurred.

To remain compliant, CSPs must offer "Sovereign Support" options. This guarantees that only screened personnel physically located within India can access infrastructure tiers where plain-text financial or personal data could potentially be exposed.

Downstream Sub-Processor Controls

If your cloud platform utilizes third-party SaaS tools or specialized microservices to provide features like automated log indexing, security analysis, or performance monitoring, those vendors are legally classified as sub-processors.

Under the DPDP Rules, you must contractually obligate every sub-processor to maintain equivalent security safeguards (Rule 6). You must also maintain an up-to-date, transparent register of these sub-processors, allowing your financial enterprise clients to review or object to any entity handling their downstream data pipelines.

6. Audit-Ready Foundations and Sovereign Assurances

Indian financial regulators do not operate on an honor system; they require definitive, auditable proof of compliance. Both the RBI and the DPBI reserve the "Right to Inspect" any infrastructure handling local financial data.

Physical and Logical Access for Auditors

Your contractual agreements must explicitly allow regulators or nominated third-party auditors (such as CERT-In empanelled auditors) to inspect your physical data center facilities, security control frameworks, and logical isolation boundaries within India.

Continuous Artifact Delivery

To help clients pass their annual regulatory reviews, CSPs should provide an on-demand compliance portal stocked with verified, localized artifacts:

 

• System Audit Reports (SAR): Specialized audits specifically mapped to RBI’s payment data localization circulars.
• SOC 2 Type II and ISO/IEC 27018 Certifications: Detailed reports confirming operational control over data privacy in public cloud environments.
• Tamper-Evident Logs: Cryptographically signed logs that prove local data retention parameters have been maintained without alteration for the required 12-month window.

Moving Forward: Privacy as a Competitive Advantage 🎯

For Cloud Service Providers in India, data localization and DPDP compliance should not be viewed merely as regulatory hurdles or checklist items handled by the legal department. They represent a fundamental shift in how enterprise software must be architected for the Indian market.

As financial institutions face increasing scrutiny from the RBI and the DPBI, they will naturally migrate toward infrastructure partners that minimize their compliance risk. Cloud providers that design their platforms with data residency by default, absolute cryptographic isolation, rapid forensic telemetry capabilities, and transparent supply chains will establish themselves as trusted operators in India's digital financial economy.

Building a compliant financial cloud requires shifting focus from simply providing raw compute power to establishing a secure, verifiable, and sovereign data perimeter.

Cloud Computing - Governance Challenges

I recently happened to read a Technical Note published in October 2006 by Software Engineering Institute titled as ‘System-of-Systems Governance: New Patterns of Thought’. The technical note was primarily aimed at organizations like Department of Defence, where in multiple organizations and systems need to collaborate to form part of DoD as the bigger enterprise. The Note discusses about some of the key areas where the traditional Governance would need a review and revision to handle the very nature of the System-of-Systems.

CIOs are in favour of embracing cloud and as such would have contracted for multiple software systems (SaaS) for different needs, for instance Salesforce for its CRM needs, ServiceNow for its IT Service Management, Windows Azure for custom application development, NetSuite for its ERP needs and so on. Similarly the IT organization would have contracted with different cloud service providers for its Infrastructure (IaaS), Storage and Platform (PaaS) needs. The XaaS list is growing as we are now seeing offerings from vendors for Database as a Service, Security as a Service, Identity as a Service, etc. With all this multiple contracted system components, the IT organization certainly has challenges in implementing governance practices, as there are diverse systems components forming part of the larger system.

In today’s world, with increasing cloud adoption and outsourcing activities, we could see business organizations are in almost in the same state as it is described of DoD, i.e. System-of-Systems and the key governance challenges very much hold good to be addressed. The following are the five amongst the six areas that need to be looked into to realign the governance practice within an enterprise:

Collaboration and Authority

With systems and components owned by various organizations being in use, even if owners of constituent systems are unusually committed to the system of systems, a single authority is likely to be ineffective. And if authority is essential to the enforcement of IT policy, then without sufficient or inadequate authority independent vendor organizations can always be expected to have reluctance in adopting shared policies. Collaboration amongst the constituent system owners is required at least in problem solving, participating in decision making process, coming up with provisional solutions to meet an emergency need. While the cloud computing is still maturing, there is a need for standards to emerge which should facilitate the necessary collaboration both technically and in terms of policy federation.

Motivation and Accountability

There should be motivation for anyone to adhere to or adapt to a shared policy. Enforcing such shared standards or policies across independent vendors would not work as effectively. The Technical Note refers to Zadek’s five stages of learning that organizations go through to achieve the benefit of voluntary collaboration. These are:

Clic on the image to view a better image

The table above not only shows what motivates organizations at different stages but also reveals what they may need to learn. For example, a defensive organization that claims common system-of-systems practices are irrelevant may need to be educated about threats to its reputation due to its lack of voluntary compliance. At all stages, we need policies to give individuals and organizations the incentive to do the right thing.

Multiple Models

A simple example to highlight how this area is significant could be the security implementation within the component systems. Each component and system vendor may have different security models implemented within the individual systems and that complicates the governance of the overall organization challenging. This calls for the need for a dynamic governance model, which can map and interact between different models of the individual components. While security is just one example there are other areas where the components are designed and modelled differently. While framing the Governance policies to suit all such systems certainly is not the good approach, the governance framework should provide for variables based on type of systems or type of service or a similar category.

Expectation of Evolution

This can be easily related to change and release management of independent vendor systems and the change of the common infrastructure of the enterprise itself. If governance cannot eliminate the independent evolution of components within the system of systems, it should aim to reduce the harmful effects of uncontrolled evolution by the component systems. Thus, policies must be created and enforced to provide rules and guidance for components as they change.

At a minimum, governance for evolution should include rules and guidelines for

• informing other components systems (when known) 12 of the changes in the interfaces to and functionality of one system
• coordinating schedules with other component systems so that those that have to change can do so together (when backward compatibility of interfaces cannot be maintained)
• maintaining multiple versions of the system when schedules cannot be coordinated
• developing each system to insulate it from changes in other component systems
• minimizing the perturbations to interfaces when changing a system

Highly Fluid Processes

Agility is the order of the day within every function of the enterprise. Being agile and responding to changes quickly gives the competitive edge to the enterprises and that is equally applicable for the Governance Framework as well.

Planning for rapid changes in system-of-systems governance is needed. For example, governance strategies may provide a mechanism for adapting to rapid policy change, such as a way to relax security policies to achieve some urgent goal and then tighten them up again. Governance policies should be framed in such a way that those around the systems or components which is likely to see problems or changes too quickly should have flexible policies and whereas as we move away from such systems, it should be relatively stable. For example, a neighbourhood of closely related systems might be the first to notice a problem with a current component or process and will need to respond quickly. At the extreme, where neighbourhoods of related systems are themselves fluid, some details of system-of-systems governance policies might be negotiated.

Summary

As with the technical note, I have not attempted to suggest solution for the governance challenges listed above. Organizations like ISACA have been researching on Governance issues and its widely adopted COBIT framework would have solutions for these problems, which we will explore in my future blog posts.

References:
SEI's Technical Note - System-of-Systems Governance

The pressure points of Cloud Adoption

The values and benefits of cloud adoption is increasingly clear and well known. Not to be carried away with these values and benefits, it is important to identify and be aware of the pressure points that the Cloud Adoption brings in as called out by ISACA in its white paper titled as ‘Guiding Principles for Cloud Computing Adoption and Use. Essentially the differences in technology itself and its use impacts the way IT is governed and managed and the management’s reaction to these impacts brings on the pressure points as well, which need to be managed.

Differences such as change in cost allocation from capital to operational may have consequences that may not apparent at the beginning. For instance, contracting for a cloud based software would be an operational spend and may have a lower cost of entry and thus, such decisions may fall outside the review and approval process. While in most cases, the pressure points are to be managed as risks, these are not necessarily risks.

Speed and Agility

The time-to-market is a driver for cloud adoption as solutions to meet market needs would be available more quicker at lesser cost though there could be gaps in meeting the exact requirements. This agile exploitation in a reduced time frame puts greater pressure on enterprise, in which culture, process, and human factors related to technology have been developed to support longer development cycles and long term technology use. This pressure when not handled appropriately could result in increased risk level in the following areas:

• An unbalanced prioritisation of value over trust in technology solution choices
• Missed opportunities when other alternatives are not considered
• Recovery mishaps because fallback positions are not fully exploited
• Missing functionality if full requirements are not identified
• Increased long-term costs due to reliance on multiple short-lived solutions
• Reduced performance when enterprises are hesitant to introduce new solutions because of existing technology investments

Changing Boundaries

The reliance on cloud providers calls for change in the roles and responsibilities within the enterprise and transfer certain responsibilities to outside parties. Contracts and SLAs with service providers attempt to assign accountabilities, but governance dictates that the enterprises themselves, their board and management remain accountable. With this, the locus of decision making changes from governance functions to business line leaders. This change in the organizational boundaries can put greater pressure on enterprises. The risk outcomes out of this pressure point could be:

• Role confusion when accountabilities and responsibilities are not clearly defined
• Diminished effectiveness when decisions are made without engaging in a wider consideration of trust and value before cloud acquisition
• Failure to satisfy constituent and end-user expectations for protection and privacy
• Project delay and increased costs due to the need for personnel with governance responsibilities to revisit cloud plans
• Unclear specifications of provider responsibilities and accountabilities in SLAs
• Incomplete information being provided to board members and senior management

New Technologies and Technology Expectations

Cloud follows a sequence of disruptions in how technology is viewed, integrated into organizational strategy and managed and in how IT risks are identified and managed. Areas of high pressure can result when strategy and enterprise architecture do not consider the unique qualities of cloud computing and when enterprise processes and procedures do not easily adapt to changes made possible by cloud computing. The following risks could be the outcome of this pressure point:

• Missed opportunities to extract value from the integration of cloud and internal systems
• Increased vulnerability from incompatibilities and inconsistencies between cloud and internal systems
• Less than expected results when human factors are not considered in the design and integration of cloud services and infrastructures
• Levels of organizational performance that do not meet expectations because cloud solutions do not fully support organizational processes
• Levels of technical performance that do not meet expectations because processes do not take full advantage of cloud capabilities

Level Playing Field

Cloud computing removes the advantage that large enterprises have traditionally had in terms of availability of technology specialists and technical sophistication. Smaller enterprises now have the ability to leverage the cloud services and use technology sophistication that large enterprise used to enjoy. This brings the small and medium enterprises on an equal position with much larger enterprises. This level playing field can have an impact on the strategy and its implementation. Ignoring this impact can result in increase of risk levels in the following areas:

• New entrants claiming a segment of traditional market dominance
• Strategies that do not address competitor capabilities
• Less-than-expected benefits received from technology-dependent solutions

Utility Services and Service Supply Chains

With cloud computing, where computing is viewed as a utility, focus is shifting to the value and benefits obtained from such utilities. Agile enterprises benefits from solutions that can be used as needed and discarded when they no longer provide value. This view of computing as a utility and the delivery of solutions supply chain of information systems solutions puts greater pressure on enterprises that contain a culture that is not accepting of utility solutions, a structure that does not facilitate cooperative planning and processes that cannot take advantage of computing solutions provided as supply chain of utilities. Ignoring this could result in the following risk outcomes:

• Over-investment of resources in planning and building internally developed information system solutions
• Less-than-optimal results when value-producing cloud utilities are missing from the total solution
• Duplication of effort when specialist services available through cloud providers are not integrated as part of system management
• Less-than-expected results when utility components are not integrated into and managed as an information system capability supply chain

In the white paper, ISACA suggests that enterprises follow a six guiding principles that can help illuminate the path for cloud adoption. Click here to download the complete white paper which is available for registered (free registration) users.

Emerging Cloud Trends – Impact on IT

A recent Gartner Report identified five Cloud computing trends which could affect the cloud strategy through 2015. While Cloud Computing has a significant potential impact on every aspect of IT, the uncertainty, confusions and misunderstandings continue to exist and the five sub trends would be accelerating and need to be factored into the planning process. This means that the CIOs would be inclined to revise the cloud strategies to align with these trends. This will also mean that the enterprises would need IT workers with skills that could help in making this strategic shift successful. Here are the five sub trends and the skills that these trends would demand.

Formal Decision Frameworks facilitate Cloud Investment Optimization

The benefits of cloud include the shift from CAPEX to OPEX models, reduced spending, greater agility and reduced complexity. These benefits do not come just like that and they come with some challenges in the form of security, lack of transparency, performance & availability concerns, vendor lock-in, licensing constraints and integration needs etc. It is important that these benefits and concerns are carefully mapped against the needs of the enterprise and an appropriate decision is made and necessary monitoring and management processes are put in place. Each of these benefits needs to be quantified considering the organization’s current and future priorities and constraints. For instance, a financial services firm may find the greater agility as a challenge as well (as against a benefit), because, greater agility could mean more frequent changes, which would have an impact on the reliability and stability of the applications. Realizing such impact in mid-course could result in rolling-back from cloud adoption and the resulting impact is obvious.

Over the next few years, organizations would be putting in appropriate decision frameworks, more specifically for the cloud adoption so that the benefits and risks are known upfront and decisions are taken appropriately. The skills that this trend may demand include Risk Management, IT Security, IT Governance, Estimation and Metrics.

Hybrid Cloud Computing as an Imperative

As there are enough reasons for enterprises not moving all their IT on to public cloud, Gartner sees a unified cloud model, where a cloud of clouds is a possibility, in which a single cloud may comprise of multiple cloud platforms part of which could be it internal. As everyone know, the key challenge with hybrid cloud computing is the integration of application and data between on-premise and cloud applications.

This calls for existing internal applications being enhanced to support integration with external cloud applications and at the same time the cloud applications should expose APIs for consumption by other cloud applications and / or the organization’s internal applications. Applications on public cloud need to adhere to industry standards and best practices, so as to support varying integration needs of its customers. The skills that an IT professional would start seriously looking at to get on with this trend are EAI (Enterprise Application Integration), SOA (Service Oriented Architecture), ETL (Extract Transform and Load) and EII (Enterprise Information Integration).

Cloud Brokerage will facilitate Cloud Consumption

As cloud adoption proliferates, so does the need for consumption of assistance. Gartner believes that Cloud Service Brokers (CSB) are one of the most necessary and attainable opportunities for service providers, service distributors and internal IT organizations. The CSB model provides an architectural, business and IT operations model for enabling, delivering and managing different cloud services within a federated and consistent provisioning, billing, security administration and support framework. This will help the unification of the cloud services delivery and management. Gartner has designated Jamcracker as a “Cool Vendor in Cloud Service Brokerages”.

This trend will call for the IT professionals to have a great deal of knowledge on SOA in addition to various standards, practices and tools on service provisioning, delivery monitoring, billing and management.

Cloud-Centric Design becomes a necessity

Migrating existing workloads with highly variable resource needs to cloud platforms is among the immediate opportunities that many organizations are looking at utilizing. But this will not make the cloud adoption complete, as it will result in using various work-around approaches to make it work with existing applications, by-passing standards and best practices. This might work in the near term and but may not scale and yield the real benefits in the longer term. Organizations should start looking at development of cloud-optimized applications that exploit the potential of the cloud. Even internal applications should be designed with cloud-centric model, so that it can exploit the private cloud platform and would make the integration with public cloud applications easier over hybrid cloud computing platforms.

This trend will expect the application and solution architects to start acquiring necessary cloud skills, so that the solution that they architect is cloud-centric and will have identifiable service end points for use with various other internal and external applications and also factor in the support for Cloud Service Brokerages. The design patterns, standards and practices around cloud-centric design is evolving and it is important for the IT workers to keep a watch in this area.

Cloud Computing influences future Data Center and Operational Models

In public cloud computing, the providers have implemented such a model so that the ability of provisioning, delivering and managing the services is optimized and automated to a great deal. This also ensures optimal utilization of the underlying hardware and also minimizing the energy and other operational costs. Enterprises are attempting to implement the similar models within their data centers and have private clouds setup for the consumption of their own internal consumers. This trend is increasing and Gartner predicts that in the next few years any data center (small or big, internal or external) implementation would follow the cloud model.

This trend will expect the Infrastructure Architects to be cloud aware and be familiar with the underlying tools and technologies, which form part of the cloud service provisioning, delivery and management.

Reference: Gartner report "Five Cloud Computing Trends That Will Affect Your Cloud Strategy Through 2015." The report is available on Gartner's website at http://www.gartner.com/resId=1920517.

SaaS Security and Compliance Concerns

Security is one of the major concerns which hold enterprises from embracing the cloud. But some think that this is manageable and as such have started adopting cloud based SaaS applications. Cloud based Enterprise solutions like Sales Force, Service Now, NetSuite are gaining ground. Let us attempt to list down some of the key areas, where the security and compliance needs are different from the on-premise applications.

Data Security 

Unlike on-premise applications, in case of SaaS applications, the underlying data is located outside the organization’s physical / logical boundaries. If the SaaS Provider in turn has hosted the application with a Cloud Platform or Infrastructure provider, then it is true for the Saas Provider too. This very fact that the data is located outside the enterprise could be a serious security concern for some enterprise, depending on the sensitivity of the data and the laws governing them.

Mature SaaS applications do expose Service Interfaces to facilitate data integration with other on-premise applications of the enterprise. Which means these Interfaces also need to be equally secured as these can be exploited to steal or manipulate data.

This means that the data as stored elsewhere should be secured by well established practices and methods like encryption, access control, etc. In addition, all the interfaces that expose data should also be secured using appropriate access control, authorization and logging techniques. The SaaS provider shall also make the data access logs available to the enterprise for review and audit.

Another important area to be concerned about is upon the service termination, how the provider ensures the proper return of the complete data and also make sure the destruction of copies maintained as the services may require.

When the SaaS provider assures adequate back-up and recovery tools and processes, it should also be ensured that the location of the back-up data is physically and logically secure enough and the data is stored with an acceptable form of encryption. Again, access to such locations should also be controlled, so that the SaaS consumers could access only their very own back up data and not that of others.

Data Segregation 

One of the key characteristics of SaaS application is multi tenancy, where an application instance is shared with multiple customers. That means, the customers’ data as handled by the application needs an appropriate physical or logical segregation, so that users of a customer access only their own data. On the consuming enterprise front, this could be a big concern as lack of adequate control could result in data being accessed by other consumers of the application, who could be competitors.

In this context, it is essential to know how the application and data stores are architected and what controls are in place to ensure isolation of customer’s data to its own users only. This is a larger issue and a lapse in one of the following areas could result in a compromise:

• A design or architectural flaw in the user authentication and / or authorization 
• A design or architectural flaw in the customer data separation 
• A defect in the user authentication routine 
• Regression issue caused by a design or application change 

Development Model 

 As we understand, how a flaw or change in the application could compromise the data security, the SaaS provider should also assure the consumers that their application design development model is developed to address the SaaS Security concerns. This means that the SaaS provider should have the following practices as part of their application design and development model.

• The developers should be security aware and the design and code that they produce should be of high standards. The development team should be well trained in remediating security threats as they are detected. 
• The development lifecycle should provide for security reviews and security testing at the end of every phase / sprint 
• As the application instance is shared by multiple customers, there could be need for customer specific patches and far more quicker releases of smaller changes. This may require agile development methods to be adopted. 
• The engineering process should include a configuration management process as the shorter release cycles and customer specific patches would require better source code control and more specifically in code branching and merging. 

Infrastructure Security 

Like in-house production environments, the environments where the SaaS application is hosted should be well secured. The SaaS provider should establish this fact by exposing the process and practices followed for the purpose by adhering to the popular security frameworks and standards. This need is the same as like in case of on-premise or cloud hosted enterprise’s own applications.

Regulatory Compliance 

There are a number of legislations in various countries, which stipulates for compliance to certain processes and practices when it comes to data. For instance in US we have HIPAA, SOX, etc. The SaaS model complicates this further as the enterprise may be operating out of a location in a country and the SaaS provider may be operating out of a different country and the data could be located in yet another country or even countries.

Again, in the SaaS provider perspective, customers from all over the world may subscribe for the application and in which case, the provider should establish necessary compliance practice to meet all such legal requirements. Some countries have legal requirements to retain data for certain minimum period, which the SaaS vendor should support.

It is needless to say that the governments would be monitoring the cross border data traffic and would seek clarifications and explanations and for which adequate audit trails and logs are essential.

Identity Management 

Provisioning users and managing their access and authorization permissions for various applications is becoming increasingly complex and enterprises are looking at central identity stores coupled with single sign on to address this problem. With SaaS, this could bring in additional complexity. Most enterprise SaaS application providers offer support for local store and as well as integration with enterprise’s very own identity store.

In case of local identity store, adequate security around the identity store and the process around managing the identity store gains significance. Any lapse in this area could lead to data a compromise in data security.

In cases where integration with enterprise’s own identity store is preferred, then the additional concerns could be in the areas of establishing trust relationships with the SaaS application and securing the federation of user identities between the identity store and the cloud hosted SaaS application.

Conclusion 

Adopting a SaaS application does not absolve the enterprise from governing the information assets associated with such application. The CxOs of the enterprises will still be responsible whether these are managed on-premise or by the SaaS vendor. The SaaS vendors in turn should make sure that they comply with all these needs so as to win the confidence and trust of the enterprise for selling the software services.

Check out my presentation on the same topic on slideshare.

Driving fast into the Tech Lane

As I was driving down to a restaurant with a friend of mine, we were chatting about another common friend and his new venture on mobile applications. The conversation soon gained technical flavor and it was a nice drive into the fast changing technology lane. Here are some excerpts from our conversation during the drive.

On why enterprises are in a hurry to port existing applications to mobile platform...

The technology is evolving so fast and enterprises will soon be embracing mobile devices which range from smart phones to tablets. Every tech worker owns a mobile smart device of his or her choice. Most such workers are holding senior positions in the enterprise and are very keen to use it to perform their work and for the purpose, try to influence the IT heads to allow such devices in work environment. This in fact is a challenge for the CIOs in terms of information security and confidentiality. But as this trend is growing, the IT heads have no option than to embrace this trend and start regulating this with a formal BYOD (Bring Your Own Device) policy, controls and governance framework around it.

On how BYOD is relevant in the context of mobile applications...

Yes, as the BYOD is gaining increased acceptance, the next big challenge is to get existing applications working on such devices, so that the employees don’t have to be provided with a desktop or even laptop. This in turn drives the need for porting the applications to mobile platform. Many tools and methodologies are emerging in this space so as to facilitate building mobile applications from ground up and also to port existing legacy applications to mobile platform. Write once deploy any where is the USP for today’s development tool vendors.

On how legacy applications can be ported...

This is where the Service Orientation is gaining importance. Business services are identified and exposed as reusable services and then build a portal application on top of it to appropriately present it for end user access on a variety of devices. The organizations would also consider embracing the cloud based SaaS applications to replace the legacy applications. And yes, migration to cloud could be a daunting task but CIOs are seeing a longer term benefit in doing so. An alternative shorter term solution could be to get a virtual desktop on the mobile device and then work on whatever legacy app that runs on the desktop.

About the concerns on cloud...

Yes, there still are certain concerns that keep organizations away from the cloud. However this trend is changing. Most organizations have already moved less critical applications to the public cloud. Like we have central / reserve banks regulating the banking industry, it is time for the industry consortium to come up with an independent regulatory body / framework, which can help establish the trust amongst the enterprises, which in turn will ease some of the security concerns. While industries like Banks and healthcare providers have reasons to be concerned to embrace cloud, other industries are showing serious signs of embracing the cloud.

On the amount of data that banks process and manage and whether that could be a deterrent for cloud adoption...

Be it cloud or not, data quality and data maintenance is going to emerge as a critical function. Dirty data and redundant data is being identified as having considerable impact on the profits of the organization. Tools have emerged in assuring data quality, data de-duplication and master data management. Computing hardware and related technologies like virtualization has made vertical and horizontal scaling very easy and thereby making the usage of these data intensive tools a possibility.

We both enjoyed this conversation and I am sure, you would also enjoy reading this. 

SaaS Maturity Level

Cloud is catching up amongst enterprises. Amidst the security and the other concerns that are still to be addressed, CIOs are seeing a clear benefit in shifting towards the Cloud offerings. That means, there is an increasing number of enterprises seriously engaging cloud based applications. This necessitates the need for a model to measure or assess a SaaS application. Like we have Capability Maturity Model to assess a software development shop to be at a particular level, we need a maturity model to assess the SaaS application.

Microsoft way back in 2006 suggested a 4 level maturity model using Scalability, Multi-Tenancy and Configuration to define various stages. While Level 1 is meant to define an ad-hoc hosted application which lacks all the three basic fundamental characteristics and at Level 4 a SaaS application is expected to meet all these three basic characteristics. This model has its own deficiencies as it does not consider few other important characteristics of a SaaS application, like for instance managing the releases, data isolation, etc.

Forrester has come up with the six level definition of SaaS Maturity. Let us examine each of these levels as below:

Level 0: Just Outsourcing, not SaaS. This is a typical scenario where a service provider operates a software installation for a large customer and cannot leverage this setup for another customer. This is just outsourcing and not SaaS.

Level 1: Manual ASP (Application Service Provider). In this case, the service provider has established unique skill in operating similar service to multiple customers, but each client has a dedicated instance and each instance is manually customized by the service provider to the needs of the customer.

Level 2: Industrial ASP, still not SaaS. The Application Service Provider uses techniques to package and deploy the application with different configurations for different customers. In this case, still the customer does not have the ability to customize their instance of the application.

Level 3: Single-app SaaS. This is when the provider is able to offer application  as service to multiple customers out of single packaged application. This is the initial level of SaaS, wherein the application demonstrates some of the basic characteristics of Software as a Service.  At this level, the provider deploys the packaged application on a scalable infrastructure, and shares the single instance to multiple customers with customization limited to configurations.

Level 4: Business Domain SaaS. At this level, the provider offers a well defined business application and also a host of packaged application modules or third party packages, with which the customer has the ability to extend the business logic of the application.

Level 5: Dynamic Business Apps as a Service. This level is a visionary target where in the provider offers a comprehensive application and integration platform on demand. With this ability, the provider can compose tenant specific and even user specific business applications or services.

SEI has in line with the popular CMMI for development, presented CMMI for services packing in some of the service specific process areas in addition to typical development related practice areas. This however is used to assess an organization offering services as against assessing a SaaS product.

As of now, none of the models are popular amongst the major SaaS vendors, may be because of not enough competition on the SaaS space. Once major players compete on SaaS space, then customers for sure will find a way to assess the service maturity and that could be the way forward.

Please throw in your comments.

Characteristics of SaaS Applications

The evolution of Cloud Computing has paved way to enterprises look at subscribing for SaaS applications as against licensing an application for exclusive use. The primary benefit being the cost savings due to centralization. As more and more enterprises are looking for Cloud and SaaS model for its application needs, the product companies are exploring options to enhance their existing products so that they can be offered on SaaS model. It is important to understand the key characteristics of the SaaS applications before planning for the conversion.

While the application should be accessible over the web is an important characteristic, the following other characteristics are also important to look at:

1. Multi-tenancy

Typically all applications support multiple users. But a SaaS application should support multiple users of different organizations. Which means there should be a mechanism to identify and appropriately differentiate the users of a specific organization. That is the application should support multiple tenants. The tenants would also be interested to have their data be isolated and not to be mixed up with that of other tenants. At the least, the SaaS application should have the ability to uniquely identify each and every data record against a tenant.

2. Subscription and billing mechanism

Organizations are embracing SaaS applications on the premise that they will be paying far less based on one or more parameters, which measure the usage by the specific tenant. For instance, SaaS application may be priced based on number of users or based on subscription and use of specific modules / features. Some times, the pricing may be even complex, where it could be based on the transaction volume or a combination of one or more such measures. So, the application should be capable of tracking and logging such parameters and that the billing could be automated.

3. Scalability

A typical web application is hosted on a separate instance owned and exclusively used by a specific tenant. Whereas in case of SaaS application, the provider owns the hosted instance, which is used by all the tenants. Though the provider has the option to host a separate instance for each tenant, the economy of scale would at its best when a single instance is offered for multiple tenants. Depending on the application's features and the wide reach amongst the potential customers, the customer base could grow so fast and the application should be scalable both horizontally and vertically to support the unexpected growth in volume.


4. Manageability

The tenants should have the ability to manage their part of the application including managing the users, roles, permissions, etc. As the subscription base grows, it would be ideal to leave the application management to the tenants themselves. This requires the application to have necessary features / functions for use by the tenants.

5. Self service sign-up

While self service sign-up is not a key characteristic, it is a highly desirable to have this feature when the customer base is expected to grow too fast. Similarly, on boarding a customer may involve data migration from a different application used by the tenants before. The SaaS application should expose appropriate interfaces / APIs to facilitate the migration. It would also be a desirable to expose APIs to facilitate export / back up of data by tenants themselves.

6. Tenant specific customization

Typically, product companies undertake to customize an application to meet the specific needs of the customers by enhancing the application. But this would not work in case of SaaS application, as all the tenants would typically be using the same version of the application. That means, the application should be highly customizable, so that it satisfies the specific needs of all the tenants. In a large scale SaaS application this is achieved by providing the ability to extend the application by defining and deploying specific screens and scripts by the tenants themselves.

That is not all. There are other characteristics too and some of them could be key depending on the nature and demands of the industry and the providers. Please feel free to share your thoughts.

Here are some useful reference links that deal with the SaaS application challenges and characteristics.

• SaaS: an Enterprise perspective
• Challenges in converting existing web applications to a multi-tenant solution

Future of Personal Computer

With the evolution of smart phones and tablets, the survival of Personal Computer could be under threat. Let us examine, if there is a possible thing that PC alone can do.

Thick Client Applications: We have started seeing the increasing number of applications moving to the cloud and one just need a browser and may be an appropriate pug-in to run a cloud application. Even heavy weight applications like ERP suites and Business Intelligence Suites are now being offered over the cloud. In few years from now, I don't think there will be any compelling need to use a thick client application.

User Convenience:  Yes, a bigger monitor and a regular keyboard with a mouse will really be convenient to work on a PC. But do we need a PC just to have a bigger display and the key board? Not really, some of today's smart phones are dockable on to a device, which facilitates connecting to a bigger display and keyboard.

Higher Computing Power: When the applications are served out of Cloud, much of the processing happens elsewhere on some server(s) located over the cloud, and not much power is required on the client device. That is not the end, in few years from now, the smart phones / tablets will equally sport a high end processor with even multiple cores.

Extreme Gaming: Most of the popular games today are online games. Gamers also prefer online games which connects buddies from all over the globe to join and play together. More so, because the gaming service providers gain more in the form of Ad revenues in case of online games than Thick client games. Above all, there are special purpose gaming consoles in the market for extreme gaming.

Enterprise Computing: While it could be ideal to go with enterprise owned secured and locked down personal computers to access and process enterprise information, but that does not mean that they have to be PCs. Even now most enterprises are encouraging their employees to work from home on a Laptop, there by saving so much of energy costs at the physical location and at the same time commuting time for the employee. The evolving tablets could easily replace the Laptops.

Research firm Gartner slashed its growth forecast for the global PC market this year to 3.8 percent from 9.3 percent citing boom in media tablets.

You name one thing, we can think of how tomorrow's personal gadgets could address that. Would like to here from you on this trend.