Tag: data privacy

  • Positioning Compliance as a Differentiator

    Positioning Compliance as a Differentiator

    As the threat landscape has become more perilous and complex, regulators have imposed a wide array of mandates designed to protect sensitive personal information. For most organizations, compliance is seen as the cost of doing business. However, if executed strategically it can not only improve a company’s overall security posture but shortens sales cycles and open the business to new markets.

    In order to turn compliance from a check-the-box line item into a valued business initiative, businesses need to identify all global, local and industry regulations that apply to their business and, also, strategically implement the processes and technologies that keep them compliant. Whether you’re targeting specific industry verticals or going after international customers, entering new markets requires continuous education about the latest in compliance and regulatory standards as they relate to data privacy and security.

    A good way to get started is to put together a roadmap for how you will get, and stay, compliant with the regulations relevant to your business. What follows is an outline of such roadmap.

    Start with the Basics

    When you’re building a house, a foundation is the key to a safe structure. This holds true for building a compliance roadmap for an IT infrastructure.

    The first step is to ensure the infrastructure is configured in accordance with Center for Internet Security (CIS) benchmarks. If operating in Amazon Web Services (AWS), ensure all AWS best practices are met. Setting this foundation will help meet basic security and compliance requirements and will simplify the compliance journey from the very start.

    Once the foundation has been set, it’s then time for the compliance, IT and security teams to determine which regulations apply to their business. This is the backbone of the compliance roadmap. The good news is that many of these regulations overlap so businesses can complete requirements for multiple regulations at the same time.

    First Stop: SOC 2

    As a component of the American Institute of CPAs Service Organization Control reporting platform, SOC 2’s goal is to ensure that internal IT systems are configured for maximum security, emphasizing the privacy of customer data. It’s specifically designed for service providers storing customer data in the cloud, and this means it’s becoming increasingly relevant as companies continue their cloud migrations. SOC 2 goes beyond a simple technical audit though, requiring businesses to establish and follow stringent security policies and procedures that encompass the security, availability, processing integrity and confidentiality of any data stored in the cloud.

    In order to achieve SOC 2 compliance, the organization first will need to establish an understanding of what normal looks like in their environment. It’s critical to baseline typical activity in order to be able to monitor for anomalies. This enables detailed audit trails that allow for deep, contextual insight into root cause, allowing organizations to remediate issues and thus keep up with SOC 2 requirements.

    The Roadmap Focal Point: GDPR

    The General Data Protection Regulation (GDPR) brought compliance into the mainstream. When GDPR passed, it established strict regulations for how organizations with European customers must handle customer data. The regulation is so broad, stringent and complicated that it has motivated many tech companies to create new job titles to ensure compliance.

    However, while there have been strict compliance regulations before, it’s the high financial stakes attached to GDPR that set it apart. A business can be fined up to 4% of its global revenue if it’s found to be non-compliant. Very few organizations can afford to take that kind of hit which is why so many make it the centerpiece to their compliance strategy.

    The privacy implications of GDPR are extensive but one of the most important and challenging requirements is the data breach notification. Organizations must notify authorities or specific data subjects within 72 hours of a breach. Most organizations are unable to locate sensitive consumer information within their environment, making this requirement near impossible. However, if the organization bakes data controls into its systems and enacts continuous monitoring and real-time intrusion detection, it not only becomes achievable but improves internal processes. 

    Go Broad with Certification Add-Ons

    Once you’ve done the basics, like SOC 2 and GDPR, organizations can then begin looking for compliance regulations that they can actually use as business differentiators. ISO/IEC 27001, for example, is a standard that SaaS organizations often use to demonstrate an aptitude for managing information security risks. The regulation formally specifies an Information Security Management System, a suite of activities concerning the management of information risks and lays out an overarching management framework to identify, analyze and address risks. Certification requires a host of documentation, including a clear information security policy, a risk assessment process and evidence of information security monitoring and measurement. The standard spans industry type, organization size and market, so it applies to just about any company.

    Compliance can be a powerful differentiator and business driver that inspires trust and confidence amongst prospects, customers and external partners. Although the above standards and regulations require extensive resources, non-compliance can result in fines and other punishment that can cripple a company. It’s important to remember that these compliance standards and regulations may have to be revisited, but once put into place and assigned to a dedicated compliance team, the once daunting task pays for itself.

    — Lindsey Hardy

  • What It Really Takes to Build a Reliable App

    What It Really Takes to Build a Reliable App

    What makes an app reliable? If you ask most IT professionals that question, their minds immediately go to uptime. That’s not surprising; after all, it’s fashionable for software and infrastructure vendors these days to boast about how many nines of uptime they guarantee.

    To be sure, uptime is one component of delivering a reliable application experience for developers and end-users. But it’s only one. In order to build reliability into your application patterns, you must think beyond uptime alone.

    Keep reading for an overview of all the factors that go into achieving reliability.

    What Is Reliability?

    A reliable application is one that meets the needs and expectations of everyone it serves. While those needs and expectations will vary from case to case, reliability is characterized by the ability of an app to:

    • Be accessible when needed.
    • Respond within the time frame needed.
    • Be updated or modified as needed.
    • Provide security and privacy to the extent needed.
    • Meet the needs and expectations not just of end-users, but of everyone else who helps create or support the app.

    Maximizing Reliability for Cloud-Native Apps

    Achieving these features for modern, cloud-native applications requires a multi-pronged approach. The following are the core considerations to address in order to build reliability into an app pattern:

    Uptime

    We’ll start with uptime, which is the most obvious aspect of reliability. Uptime refers to the amount of time that your application is available, at least to some extent (as we’ll discuss below, merely being available does not necessarily mean that the app satisfies other requirements of reliability).

    Maximizing uptime typically involves solutions such as distributing workloads across different servers or data centers (so if part of your infrastructure fails, others remain available) and using automated failover to move a workload to new infrastructure if it fails in one location.

    Culture and processes are part of the picture, too, since you need to make sure your team is prepared to respond quickly to any incidents that arise, in order to minimize downtime.

    It’s worth noting, by the way, there can be such a thing as too much uptime. If you reach the point where adding more uptime doesn’t deliver any additional value to your organization, then it’s probably time to stop. Adding another nine to your availability, just because you can, might be a poor use of resources. So, be sure to factor this part of the equation into your uptime calculations and strategy.

    Performance and Efficiency

    In order to meet stakeholder needs and expectations, an application must not only be available, but also able to respond within the time frame required by those stakeholders. A website that is up 100% of the time but takes 20 seconds to load each page is not a very reliable website.

    This is why performance testing and monitoring must be built into your application delivery chain. You should also ensure that you rightsize infrastructure (for example, by choosing the right types of cloud instances) in order to guarantee that your applications have enough resources available to perform adequately. (Of course, this priority must be balanced with cost-control.)

    Accessibility and Usability

    An application that is available all of the time and responds quickly may still fail to meet stakeholder needs if it is difficult to work with due to poor design.

    From an end-user’s perspective, user-experience testing is the most obvious way to help mitigate the risk of poor accessibility or usability within your applications. But keep in mind that you also need to think about usability from the perspective of your own team. Make sure that access-control systems, infrastructure architectures and documentation can be navigated easily. You don’t want an application or a delivery chain that is too complex for your team to be able to support effectively.

    Security and Data Privacy

    A reliable application is a secure application. There are many obvious ways to help secure applications, such as using vulnerability monitoring tools. But remember security is not just about finding vulnerabilities as they arise or deploying certain tools. You must also build security into the design of your infrastructure, processes and culture.

    Backup and Recovery

    You don’t need to be a seasoned IT professional to know that backing up data is important for achieving reliability. When something goes wrong–which it occasionally will, despite your best plans and efforts–having a backup in place often means the difference between experiencing a blip in service and a major catastrophe.

    The thing that can be easier to overlook is the importance of having a disaster recovery plan in place as well as a backup routine. Simply backing up your data isn’t enough; you must also know how you’re going to restore it to new application instances quickly if disaster strikes. If, for example, all of your cloud-based virtual machines go down, what is the exact process you’ll follow for standing them back up? Identifying the steps ahead of time–and, ideally, scripting them so the recovery process can be as automated as possible–is crucial.

    Also important is quantifying how often you need to back up data, which is determined by a metric called Recovery Point Objective (RPO), and how quickly you need to be able to recover it to avoid serious business disruption–determined by Recovery Time Objective (RTO). Along similar lines, error budgets, which define how much time you can tolerate your production systems being down, can help you define the available time monthly for making system improvements.

    Modifiability

    Few apps are deployed and then never modified again. Instead, they must be updated or scaled constantly to meet changing needs and demands. That’s why designing an application pattern that can be easily modified is critical for achieving reliability over the long term.

    In practice, modifiability entails having the right tools (such as automated deployment solutions) and the right processes (such as clear feedback loops between ITOps and developers) in order to decide efficiently what modifications to implement. It might also involve taking advantage of infrastructure technologies (such as containers) that make it easy to update a running application without imposing downtime on users.

    Conclusion

    Reliability is more complex than it may seem. No matter how many nines are included in your SLAs, you are not guaranteeing true reliability unless you also address requirements such as performance, usability and modifiability.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi