devopsy.kinsta.cloud

Tag: privacy

How to Create an AI Acceptable Use Policy
Artificial intelligence (AI) is everywhere in development operations (DevOps), from code suggestions and test generation to incident summaries and runbook drafts. Simultaneously, shadow AI has become common, with teams using unapproved tools because they are faster or easier to access. This creates real exposure around sensitive data and regulated workflows. An AI Acceptable Use Policy (AUP) gives DevOps teams clear guardrails, so AI can support delivery without creating security, privacy and compliance issues.

Why the DevOps Team Needs an AI AUP

DevOps workflows move quickly, and AI can accelerate them further. Without a policy, speed often wins over scrutiny. A formal AUP sets expectations for tool selection, data handling and review standards, so teams ship with fewer surprises and fewer avoidable incidents.

Shadow AI is the pressure point. A study published in the Journal of Accountancy found that 59% of U.S. employees reported using unapproved AI tools at work, and many admitted to sharing sensitive information through them. This is critical to DevOps because prompts can include stack traces, config fragments, customer identifiers or internal tickets that should never leave controlled systems.

An AUP also supports compliance and audit readiness. When teams can show what tools are approved and how exceptions are handled, security and legal reviews become concrete. This results in fewer last-minute blockers and a clearer path to safely scaling AI use.

What Makes A Strong AI Policy

Governance connects day-to-day AI use to the organization’s broader security and compliance strategy, including identity controls, data classification and auditability. The policy should spell out who can approve tools and which environments can access them.

Governance also reduces operational risk in direct ways. It lowers the odds of data breaches and noncompliance by limiting access to authorized users and backing those limits with controls, audit logs and monitoring. These help defend against cyber threats and regulatory exposure.

For DevOps, governance must connect to the delivery system. If AI can write code, it needs the same change controls as any other contributor. If AI can read logs, it requires the same access boundaries as an on call engineer. Its permissions must be reviewable and revocable.

Key Components to Include in Your AI AUP

AI AUPs succeed when they translate risk into rules that DevOps teams can follow in their daily workflows. Core requirements include:
- Acceptable use and approved tools: List approved tool types and task-based uses, such as sanitized documentation and test generation. Define allowed and prohibited data classes, as small snippets can include credentials, client data or proprietary code.
- Privacy and confidentiality: Ban proprietary code, customer PII and confidential business info from public models. Require a security review before using AI with regulated or contract-bound data.
- Security controls and threat mitigation: Require single sign-on, multi-factor authentication and role-based access. Address prompt injection and AI-assisted phishing risk with verification steps and training.
- Accountability and enforcement: Name the policy owner, define triage steps, document exceptions, and set a clear path for new-tool requests with security and data-handling reviews.
Real-world social engineering falls under the AUP because AI increases an attacker’s efficiency. In one study, AI-generated phishing emails achieved click rates of about 11% compared with about 14% of human-written versions. The policy should turn that risk into routine practice by requiring out-of-band verification for unusual requests and strengthening account recovery controls.

Tips for Implementing Your AI AUP

DevOps teams should stick with what fits their day-to-day, so every rollout feels usable and ongoing. Focus on concrete enablement steps and work these into the routines. Run short training sessions built around real tasks and designate a place where everyone can find the approved tools and allowed use cases.

Review the internal policies versus external AI security guidance on a regular basis, so the team can remain aligned as models, features and risks evolve. A good example of rules to follow is the Cybersecurity and Infrastructure Security Agency’s guidance on policy enforcement and engineering controls.

Securely Innovating With AI in DevOps

AI is already part of the toolchain, whether or not a policy exists. An AI AUP makes that reality governable by turning informal habits into transparent and reviewable decisions. When teams know which tools are acceptable and which data are off-limits, AI becomes a disciplined advantage rather than a quiet source of risk.
May 21, 2026
The Practicalities of Open Sourcing

I’ve been deeply immersed in the world of developer products for the past decade, and let me tell you, I’ve been quite the open source enthusiast. Over the years, I’ve had the pleasure (and occasional pain) of shepherding open source projects of all shapes and sizes. It’s almost become a rite of passage in some teams – the moment when your APIs and libraries step into the spotlight. After all, customers want to know what kind of software is going into their code concoctions. But, let’s be real, I’ve also witnessed open source used as a bit of a smoke-and-mirrors exercise. So, if you’re contemplating the daring act of open sourcing your projects, here are some things to know before you set out.

Manage Your Expectations of External Contributions

If I had a penny for every open source manager disappointed by unrealistically high hopes of a flood of external contributions, I’d have enough pennies to… well, still not meet those expectations. The truth is that the majority of open source projects never witness a bustling community of external code contributors. Just because your software is popular doesn’t guarantee open source success. Open source is like nurturing a garden; it takes time and effort to grow. Building a community involves shaping your APIs, fine-tuning functionality, defining boundaries and managing expectations. Expecting an avalanche of external contributions in the early days is a recipe for disappointment.

OSS can be Intimidating

While developers generally relish the idea of sharing their work with the world, I’ve stumbled upon situations where junior engineers were a tad shy about coding in the public eye. In some cases, we’ve had to delay open sourcing because engineers wanted to tidy up their work before unveiling it to the world. Especially if your team is a mix of early-career engineers, it might be easier for senior team members to offer coaching and conduct code reviews in a more private setting without the intimidating public glare.

Issue Triage and the Support Price Tag

In theory, maintaining a public issue tracker is distinct from open sourcing the code itself. In practice, these two are closely linked. Opening up your product’s priorities to the public means putting them on display alongside real interactions and feedback from customers. This doubles the importance of being responsive to customer issues, efficiently triaging them, and setting the right external expectations. For successful open source projects, this is a genuine labor of love.

The Need for a Private Mirror

There comes a time when you need to work on something in private, perhaps in preparation for a grand launch event. Unfortunately, last time I checked, GitHub doesn’t offer private branches. You might find yourself wrestling with the challenge of setting up a private mirror. What happens when you’re juggling a significant launch on an internal mirror while simultaneously managing customer bug fixes on the open source repository? Mirrors are like trying to keep two squirrels synchronized – challenging.

Saying Goodbye to Obscurity

Some software on the internet relies on obscurity for its security. Open sourcing it would be like sending hackers an engraved invitation to a party they don’t need directions to.

Unfriendly Dependencies

If your project is tangled up with third-party libraries sporting licenses that are less open source-friendly than a cactus in a desert, you’re in for a headache. I sincerely hope you don’t run into this, as unfriendly licenses often come hand in hand with unfriendly people.

Navigating the Ecosystem: Dealing With Dependency Upgrades

Open source codebases often face a common challenge – the relentless pressure to keep dependencies up to date. This is especially true for libraries and APIs embedded in customer applications, where managing transitive dependencies and supporting older versions can be a delicate balancing act.

Teams typically adopt one of two approaches. Some isolate these dependencies in a separate namespace to avoid conflicts, while others enforce a policy to always use the latest versions. Regardless of the chosen method, open source projects frequently encounter external contributions aimed at upgrading dependencies. Handling such contributions publicly, and sometimes declining them, can be a tricky task.

Maintainers must navigate this terrain diplomatically, explaining that the proposed change might not be suitable for all users by paraphrasing, “You’re not our only customer, and this could affect many others.” This balancing act showcases the challenges of maintaining open source projects in a dynamic ecosystem.

Unexpected Benefits

Now, let’s not forget the unexpected perks I’ve stumbled upon during my open source adventures. After all, I’ve done enough complaining.

● Modernization: Open sourcing often nudges you to modernize your build and deployment pipelines because, frankly, it’s easier to get them right than to get them wrong.

● Privacy and security: Open sourcing can make addressing questions about privacy and security a breeze. In an era of regulatory crescendo, it’s your golden ticket to showcasing your data-handling ballet. It’s like saying, “Hey, world, check out our moves!”

● Building trust with customers: I’ve found some outstanding team members through successful open source projects.

● Trust in open standards and code: Organizations are increasingly placing their trust in open source software. Your larger customers might care about this more than you’d imagine.

And that’s a wrap, folks. Best of luck with your open source journey!

February 13, 2024
Developers’ Role in Protecting Privacy

We live in a world where we always expect things to happen seamlessly. Every time somebody walks into a café and signs in to the free WiFi and opens their Instagram or TikTok to stay up-to-date with trends and friends or retrieves a discount from a retailer by joining their newsletter circulation, rarely do they stop to think about how that convenience and value is derived.

Technology is the key enabler working away in the background, and developers and DevOps teams are making that happen. Underneath the slick interfaces of the apps and websites that provide these highly efficient and personalized experiences is a complex machine that relies on data to fuel it, built by developers and delivered by DevOps teams.

In many ways, data is a two-way exchange, and those end-users that are aware of this give and take appear to be happy with how the relationship works.

Indeed, several surveys in recent years suggested that the majority of consumers are happy to share their data with companies if it improves their experience. Furthermore, a significant minority are still comfortable if they have no control over who sees their data, there is no clarity around how data is stored and used, even if the organization in question has a poor reputation for data privacy.

The Privacy Balancing Act

So, if most people already accept data trade-offs in some shape or form, should developers still care about building applications and solutions that guarantee data privacy?

The short answer is yes, but as developers, that involves a tricky balancing act.

Although sharing data has become commonplace in exchange for benefits and value, consumers are becoming more aware of privacy issues. Take the EU’s General Data Protection Regulations (GDPR) as an example. Over the past five years, awareness has more than doubled in notable European markets such as the UK, Spain, Germany, the Netherlands and France.

Meanwhile, there is also commercial pressure, as employers rely on developers to innovate to remain profitable. At the same time, customers expect brands to be responsible with their data, and failure to do so at the expense of trying to commercialize a new application could be detrimental. Indeed, while the pandemic may have ushered in significant changes and altered consumers’ attitudes toward data privacy, end users remain unwavering about the importance of security.

Maintaining this balancing act is becoming increasingly complex to achieve. However, the question of data privacy is becoming a key business priority, and that means developers have a big opportunity to show their commercial value to their organizations. Indeed, companies cannot afford to get the balance wrong, and developers are central to creating the perfect formula.

In fact, the privacy conundrum has been around for a long time.

When the internet was created, privacy was not considered an issue because all content accessed online was deemed to be public. Nothing was encrypted; the introduction of email complicated things, not least because anybody on the internet could, theoretically, intercept personal data and read private messages.

This prompted the emergence of the cypherpunks, a group of cryptographers who began to contemplate what the future of digital privacy might and should look like. They started to create the tools they believed the world needed to safeguard data privacy–today, their mission is carried on by developers who value user privacy.

Why Developers Need to Be Familiar With FHE

However, securing the transmission of data is not enough, as many breaches still occur because data isn’t encrypted during processing.

So, in a world where more and more data needs to be shared to deliver the sort of experiences consumers expect, is it inevitable that privacy and security will be compromised as the volume of data exchanges grows? Not necessarily.

Fully homomorphic encryption (FHE) offers a solution, allowing developers to build applications and run services without needing to see or secure the underlying data. This is because FHE enables data to be processed blindly without having to decrypt it at any stage. FHE offers a way for developers to maintain that all-important balancing act between maintaining privacy and offering value to both business and customer.

In FHE, to guarantee a user’s data privacy, all data is encrypted by the user with their own secret key. Users of a particular service, such as an online medical portal, will use a secret key to send their encrypted data to a server where blind processing takes place. The result is also encrypted and sent back, the user again using their secret key to decrypt the information.

What this means is that, because data is encrypted end-to-end, the company providing the service can do so in a way that keeps the same customer experience, even though they cannot see the data that is being shared and sent back. From a security perspective, this is also critical. Governments, attackers and service providers cannot see the exchanged information because they do not possess the key–they also cannot break it, as the encryption used in FHE can resist attempts made even by powerful quantum computers.

Privacy can also be protected during larger-scale data exchanges that underpin collaboration between organizations and nation-states on numerous strategic programs, with each contributor able to add their value knowing that their intellectual property and sensitive information is not compromised.

Looking ahead, if developers can embed FHE into their practices on a broad scale, then a key milestone for privacy is within reach. Rather than being viewed as an objective relating to digital interactions, privacy can be treated as a naturally occurring by-product of every application, piece of software and service that the developer community creates.

June 20, 2023
Android Apps Must Let Users Delete Data ¦ RISC-V in the Data Center

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Google forces apps to make deleting users’ data easier, and the RISC-V drumbeat grows louder. (more…)

April 6, 2023
FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: The FAA’s NOTAM database gets corrupted, and Threema shows why DIY cryptography is bad. (more…)

January 12, 2023
EU Data Privacy: Try Again | SkyPilot: Choose Cheapest Cloud | WFH: Better Meetings

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: EU-U.S. Data Privacy Framework reemerges, Berkeley brings cloud selection box, and proof that remote work is good work. (more…)

December 15, 2022
Data Centers IN SPAAACE | Discord GDPR Fine | AWS Fires Dead Wood

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: The EU wants to put servers in orbit, a GDPR penalty for Discord, and Amazon has the hatchet out. (more…)

November 17, 2022
Preparing Your Android App for an Independent Security Review

As of July 20, 2022, Android developers publishing new or updated mobile apps in Google Play must declare how their apps collect, share and secure data. The new Google Play Data safety section provides greater transparency and enables users to examine an Android mobile app’s security and privacy practices to decide which ones to download. Developers can take an extra step to safeguard user trust and demonstrate a high standard of mobile security and privacy by undergoing an optional independent security review. Founded by Google and industry security partners, the App Defense Alliance (ADA) established the mobile application security assessment (MASA) program to validate mobile apps against a globally recognized industry standard.

Mobile app developers can work with ADA-authorized labs to have their apps assessed against the Open Web Application Security Project (OWASP) mobile application security verification standard (MASVS) L1 requirements to gain the MASA validation. Developers whose mobile apps have passed an independent security review will be able to highlight that distinction in their Google Play Data safety section with the independent security review badge.

Mobile security experts from an ADA-authorized lab use the MASA specification crafted from the OWASP mobile security testing guide (MSTG) through a mix of automated and manual application security testing to independently assess the Android apps against a set of checks in six key areas.

To prepare for their independent security review, developers should follow these secure coding best practices when building their Android mobile apps.

Android Data Storage: Security and Privacy

● Use the Android Keystore system to securely store credentials including passwords, private keys, cryptographic keys and other information.
● Do not store sensitive data in external storage.
● Do not write sensitive data to the system or in application logs.
● Do not cache sensitive inputs, such as password fields.
● Mask sensitive data during user input.
● Fill out the Google Play console data safety section accurately, including both app code and SDKs.

Encryption

● Check first- and third-party code to confirm the use of industry-standard cryptographic libraries and algorithms (with recommended settings).
● Avoid outdated cryptography algorithms (such as MD5 or SHA-1) for sensitive data or authentication routines.
● Do not hardcode cryptographic keys or initialization vectors (IVs).
● For security, use pseudorandom number generators (PRNG) compliant with FIPS 140-2 security requirements for cryptographic modules.

Authentication and Session Management

● Ensure API endpoints that provide access to sensitive data require authentication.
● Use randomly generated session identifiers.
● Ensure sessions terminate at a remote endpoint when users log out.
● Include password complexity requirements enforced on both the client and server sides.
● Enable brute force protection for authentication endpoints.
● Ensure tokens have a reasonable expiration/timeout.

Android Network Communications

● Transmit all app data over TLS.
● Ensure the app verifies the validity of the certificate during the exchange.
● Declare all transmitted data.

Platform

● Do not request unnecessary app permissions.
● Validate any input your app accepts from external sources and sanitize if necessary.
● Ensure sensitive functionality is protected against unintended access for security and privacy.

Code Quality

● Remove all debugging symbols from the app and libraries.
● Remove debugging code (such as hidden settings).
● Disable verbose logging.
● Account for third-party SDKs in the data safety section.
● Update third-party SDKs and remove critical vulnerabilities.
● Enable PIC and stack smashing protection in apps and libraries.

Obtaining a MASA validation from an ADA-authorized lab gives developers a competitive advantage to drive more downloads by showcasing their commitment to mobile app security and privacy. When given a choice, mobile app users are more likely to download and use Android apps with the independent security review badge in Google Play. And enterprises with higher risk control requirements like finance, health care, energy and government are more likely to purchase and use these verified apps.

August 4, 2022
Google FLoC is Dead | Meta AI Supercomputer Lives | ARM Deal is Dead

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Google’s FLoC proposal is dead, Meta/Facebook is buying RSC—a huge AI supercomputer, and Arm “will IPO” instead of selling to Nvidia.

1. Forget ‘Federated Learning of Cohorts’—Long Live ‘Topics’

First up this week: Google bows to the inevitable. Third-party cookies will soon go away, because people are fed up with being tracked. But Google’s FLoC proposal wasn’t the answer.

Analysis: FLoC is a flop

Google doesn’t want to invade your privacy. But Google does want to sell well-targeted ads. The key difference between FLoC and Topics is that FLoC buckets were automatically generated—and hence opaque, risking overlap with “protected categories”—e.g., race or gender. But the topic classifications in the Topics API are curated and have user-visible, descriptive names.

Frederic Lardinois: Google kills off FLoC, replaces it with Topics

Google’s controversial project for replacing cookies for interest-based advertising … is dead. In its place, Google today announced a new proposal. … Your browser will learn about your interests as you move around the web.
…
When you hit upon a site that supports the Topics API for ad purposes, the browser will share three topics you are interested in. … The site can then share this with its advertising partners to decide which ads to show you. … Users will be able to review and remove topics from their lists [or] turn off the entire Topics API.
…
It’ll remain to be seen if other browser vendors will be interested in adding the Topics API. [But] they all quickly turned a cold shoulder to FLoC. … The plan is to start trialing the Topics API at the end of this quarter.

A minor tweak and rename? “Yes and no,” equivocates mananaysiempre:

Yes, it still amounts to building user-tracking functionality into user agents. No, it’s not the same approach.
…
FLoC was doing unsupervised clustering of users, whereas Topics allocates users into predetermined clusters. This makes it potentially more transparent and also seems designed to work around the “protected categories” objection.

But Google has a long way to go to convince garett_spencley:

I’m glad FLoC is being ditched, but as an end-user I’m still not asking for this Topics nonsense. It doesn’t solve any problem that I have. It solves problems that the advertising industry has.
…
I’ll choose to use browsers that don’t support this.

2. Machine Learning at Metaverse Scale is Expensive

Zuckerberg’s new toy is RSC: A $400 million Nvidia-based AI supercomputer. And that’s just Phase One.

Analysis: 3.8×10¹⁸ integer operations per second is … a lot

If you rely on Open Compute Project systems for your DevOps, know that it’s no longer the bee’s knees over at Hacker Way. Meta/Facebook is investing eye-watering sums into a custom configuration of off-the-shelf hardware.

Timothy Prickett Morgan: Meta Buys, Rather Than Builds And Opens, Its Massive AI Supercomputer

If you thought it took a lot of compute and storage to build Facebook’s social network, you ain’t seen nothing yet. … To build the Metaverse … is going to take an absolutely enormous amount of supercomputing power.
…
But what is a surprise, given Facebook’s more than decade long focus on … opening up its hardware designs through the Open Compute Project, is that the … Research Super Computer [RSC] system is built from … commercially available … servers, storage, and switches. [It] probably comes down to … working a deal with some vendors who want the Facebook publicity and are willing to work the price and the parts availability.
…
[So Meta bought] 760 DGX A100 systems from Nvidia—which each … have a pair of AMD “Rome” 64-core Epyc 7742 processors … 1 TB of main memory … eight A100 GPU accelerators [and] eight 200 Gb/sec HDR InfiniBand controllers—all-flash storage from Pure Storage, and … caching servers from Penguin Computing. … At list price this machine would cost around $400 million … Phase one of the RSC machine is rated at 59 petaFLOPS … (FP64), and 118.6 petaFLOPS FP64 using the Tensor Core matrix engines. … With INT8 processing on the Tensor Cores, which is needed for AI inference, the phase one machine is rated at 3.79 exaOPS.

How much??? It doesn’t seem like news to kleiba:

I used to work at a university where my professor had been in automatic speech recognition for a long time, but basically gave up on that line of research about 10 years ago because he figured that universities simply cannot compete budget wise with the big industry players. I suppose the same will soon be true for most ML-related areas of research sooner or later.
…
Already, a substantial amount of research innovation in [Natural Language Processing] and [Computer Vision] has been coming from big companies in recent years. Of course there is a discussion to be had about what that means for society at large.

But 3.79 exoOPS? That’s the way the wind is blowing, according to sungazer:

Give it 15 or so years—this level of computation will be on your desktop. If desktops still exist.
…
Or desks.

3. Arm Bid: No Legs

Speaking of Nvidia, as I’ve said before, the Arm merger really shouldn’t go through. And it’s looking less and less likely. ARM chips are an increasing fixture in the data center—especially those that value “performance per Watt.”

Analysis: ARM M&A DOA—IPO PDQ

A veritable hornets’ nest of Bloomberg journalists have put their names to an anonymously-sourced report. The story argues that the proposed Nvidia buyout of Arm from SoftBank Group is dead. Next stop: IPO.

Ian King, Giles Turner, Peter Elstrom, Dina Bass, David McLaughlin, Ruth David and Dinesh Nair: Nvidia Quietly Prepares to Abandon … Arm Bid

According to people familiar with the matter … Nvidia … doesn’t expect the transaction to close. … SoftBank, meanwhile, is stepping up preparations for an Arm initial public offering.
…
If Nvidia manages to get the deal over the line, it would be a massive coup. … But it will be an uphill fight. … The world’s biggest tech companies rely on Arm technology, and they fear they could lose unfettered access under Nvidia.
…
Within SoftBank, there are factions. [And] the ordeal has created divisions within Nvidia. … “We remain hopeful that the transaction will be approved,” a SoftBank spokesperson said in an emailed statement.

Post-Brexit Britain would no doubt like to keep Arm independent. Here’s simonh:

Arm has I think ⅔ of its employees in the UK—mainly Cambridge—and they’re expanding the campus there. The Semiconductor Physics Group at the Cavendish Laboratory at the University is at the cutting edge globally with 18 PhD projects currently.
…
Guess where scads of Arm’s top scientists are recruited from? Arm and the University are joined at the hip. That company’s not going anywhere.

More broadly, it’s good news, thinks hatchet:

Hopefully this means NVIDIA will focus on RISC-V instead. This will be good for everyone.

The Moral of the Story: Zeal should not outrun discretion.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Reed Geiger (via Unsplash)

January 27, 2022
Balancing UX and Privacy With IoT

As more IoT devices track data to improve customer UX, privacy concerns are becoming more prevalent. How can developers strike a balance?

The internet of things, or IoT, is a system that has changed the way we perceive technology. While it has made the usage of technology easier than ever, it does come with its own set of problems. Being such an interconnected network, IoT’s main threat is its ability to pose myriad security and privacy problems.

In this article, we seek to discuss how and why privacy is becoming a rising challenge in the world of IoT. By understanding how our privacy and security will be affected, we can take the right measures to reduce our vulnerability to these threats and secure our lives.

How Interconnected Are Devices?

IoT devices come with several technical capabilities, most of which have been researched and optimized only to the extent of their functionality. Today, IoT connectivity is available in a growing number of devices and equipment. Smartphones can connect to the internet and several household appliances, which also allows people to control these items remotely. Transportation departments have begun to hash out more advanced vehicle-to-vehicle communication, focusing on improving driver and passenger safety on the road. SmartGrid interconnected technologies allow electricity providers, managers and users to monitor and control electricity use in homes, offices and places of business. Today, several people are also making rampant use of SmartHome technologies to control appliances and home security systems and use fitness trackers to control their movement as monitor their eating and sleeping habits. These trackers are connected to their smartphones for better data aggregation.

All of these connected devices pose a question: With so much data collection and data tracking being carried out by these devices, aren’t we compromising on our privacy and security?

How IoT Affects Privacy

When we consider the compromised privacy of individuals, we are talking about each individual’s loss of control over personal information. When people invest in these interconnected devices, they are not entirely aware of how much of their personal information is tracked and saved by the manufacturer in a bid to improve user experience.

An individual can lose control if someone hacks into their smartphone or computer and remotely operates other devices. There’s no doubt that our smartphones carry a majority of our information. They are linked to our bank accounts, email accounts and even systems that need authorization. In fact, experts predict that there would be about 31 billion connected IoT devices by the year 2021. Usually, hackers employ methods that are undetected, so more connections would mean an increase in hacking activities as well.

The data collected from an individual’s smartphone or laptop can give hackers a detailed look into their activities, including internet searches and purchasing power. The information is typically used to work on user experience, but also can be used to target particular products to the individual. Sometimes, this data is even sold to other organizations that are looking for a target audience to sell their products.

Rising Challenge of Protecting Data

Data is constantly being stored, transmitted and processed by different companies with the help of IoT devices. With more entry points to access data in the form of smart TVs, speakers, lighting systems, printers and more, your data is more vulnerable than ever.

IoT vendors, therefore, should have dedicated compliance and privacy rules that alter and anonymize personal data before it is stored. The aim is to prevent the data from being able to identify an individual. Cached data and data that is no longer needed should be disposed of in a secure and organized manner.

Stored data also must meet compliance with legal and regulatory mandates. This must extend to mobile devices, web presence, cloud applications and any other means by which the data from IoT devices are accessed and managed.

Affordability of Protecting Data

Yet another concern among IoT developers is the ability to provide enough security for their services. Limited budgets and manpower constraints can prove difficult for establishments to heed to privacy and security concerns. The reason so many loopholes exist is due to the fact that so many manufacturers focus solely on getting the app out into the market to attract funding without considering the damage that could follow.

With more and more people concerned with their data privacy, organizations must implement more security checks to avoid ruining their brand authority and trustworthiness due to a data breach.

Conclusion

Users today are more connected than ever, which means privacy and security concerns must be top of mind for developers. Manufacturers may argue that data collection is essential to the development of their products and the IoT market in the long run, but there must be more focus on the security of the data and personal privacy concerns. Data collection should be done in a monitored manner, with compliance to regulations from the onset. A recent survey noted that 92% of global consumers want more control over how their information is collected. The same number of people also want to enforce punishments for corporates that violate their privacy. IoT developers, therefore, must strive to find a happy medium that balances security and privacy with user experience.

July 21, 2020