I skipped over this particular gem the first 50+ times I had reason to refer to the official #GDPR regulations but, for whatever reason, it jumped out at me this week. I’m curious to hear others’ views. I’m not looking for a definitive Legal interpretation (which can’t happen prior to May anyway!) – just interpretations & views.
This is the text of Article 12.1:
“The controller shall take appropriate measures to provide any information referred to in Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. The information shall be provided in writing, or by other means, including, where appropriate, by electronic means. When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means”.
The last part is the bit I’m interested in:
“…the information may be provided orally, provided that the identity of the data subject is proven by other means”
This could/should(?) be interpreted to mean that any information provided (for example) by phone, as a result of a GDPR rights request (e.g, SAR under Article 15), can only be provided orally (e.g. by phone) if identity verification is not carried out orally (e.g. by phone).
In other words, an Organisation cannot orally give me details of information it holds on me if it has orally verified I am who I claim to be.
This seems bizarre, counter-intuitive and unnecessarily restrictive. It also seems to rule out the possibility of automated voice-based Identity Verification leading to subsequent oral provision of data since – even though there is no actual person involved in the Identity Verification process – it is an oral process.
I’m very pleased and proud to have an article commissioned for (90,000-readership) Better Software magazine. My article – ‘Agile Outside the Development Team‘ – is chosen as one of the four ‘featured’ articles and the magazine also includes a wide variety of related material (I’ve been reading it for a few years).
You can subscribe to receive the quarterly magazine – free – at the following link and, of course, I’d be happy to read any comments anyone might have on the article so feeel free to comment below…
Those of us involved in evaluating the General Data Protection Regulation (aka GDPR) and advising on how to implement it for different scenarios are well aware of the distinction between “Personal Data” and “Special Category” data and we know that our Clients need to pay special attention to “Special Category” data. However, I have been thinking more and more about scenarios where I might consider recommending Clients treat routine “Personal Data” as if it was “Special Category” data.
Read on for an example to illustrate the point, although there are more examples (and I expect there are many that I haven’t thought of). Dissenting and assenting opinions are welcome so feel free to chime in with your views.
The number of Blog posts, articles and discussions that ask or attempt to explain “How to be a BA” is a good indication that nobody really knows the ‘silver bullet’ answer. If you think you’ll find the perfect answer here…. don’t waste any more time reading on: I don’t have a ‘one size fits all’ answer either!
This is not because nobody actually knows what a Business Analyst is or does (although there are many Recruiters and Hiring Managers who obviously don’t!). It is perhaps because there are so many different types of BA, who do different things, in different roles, for different Projects and in different Organisations.
What makes an MVP an MVP…? Do you prioritize the ‘M’, the ‘V’ or the ‘P’…? Who should be the final judge of what an acceptable MVP looks like?
These might seem like strange questions but, like most things a Business Analyst has to consider, each is a simple question behind which lies a very complicated and very, very important relationship between all Stakeholders on a given Project.
For the record, and to prevent Sports fans having to read any further, MVP in this context stands for Minimum Viable Product, rather than Most Valuable Player!
NB: additional paragraph below marked with * added as a result of feedback.
So, which is more important in a software product development environment: Minimum, Viable or Product…?
The Agile Manifesto is 15 years old now. That’s 15 years… No matter how you look at it, 15 years is a hell of a long time, especially in technology. A lot has happened over the last 15 years in the world of Software, Technology, Information Systems and the Disciplines that support (or supported) these areas.
In February, 2001 (when the Agile Manifesto was published), Google was barely a baby, Windows XP was the new OS kid on the block, Industry had just been through the Y2K hype (look it up), the Dot.Com crash had just happened (look that up, too!), MySpace – the first real, modern, Social Network) was barely an idea, FaceBook and BeBo (don’t bother looking that up) were far in the distant future, as was YouTube and Skype. Twitter, Instagram, SnapChat, Pinterest and WhatsApp were so far into the future of mankind’s imagination that they might as well have been time travel, nanobots or cheap 3D Printing.
It doesn’t matter what your view on the Agile Manifesto actually is and it doesn’t matter whether you think Agile is the solution to all our IT and Software Dev problems (which it isn’t), Agile is – by technology standards – very, very ancient.
Last year, I flew to NYC on business over the 4th July weekend. I rented a car from Dollar (@DollarCars / http://www.dollar.com) well in advance. Literally from the moment of arrival, it was a very frustrating experience, including
a long, long wait for a vehicle (couple of hours, with about 15 people waiting ahead of me when I arrived and no available vehicles);
a demand by the Dollar counter staff to prepay for a full tank of fuel, even though I had Originally made the booking with an agreement to return the vehicle full of fuel;
a vehicle – eventually provided – that was not quite as clean inside as it might have been (probably because of the quick turnaround required);
You know the horror of having to change your password for your email address or some other login…? It is a nightmare to come up with a new password that you’ll remember and that will be strong enough to resist all of the hundreds (thousands?) of different hacks, exploits and attacks happening seemingly every week… So, when you painstakingly choose a new password, it’s only natural that you’ll use the same password (or a minor variant of it) when you later have to reset some other password.
Increasingly, workplace systems that require passwords are set up to force-reset passwords every 30 or 45 days (or whatever). This, of course, means you have to reinvent your password – and it has to be easy to remember yet hard to ‘break’ – every month or two.
Naturally, you don’t write down your passwords. That would be stupid. Instead, you save them in a note or an email, on your phone or on your PC or laptop, maybe synchronised to some public cloud storage provider… After all, who could know that your file call ‘blah.doc‘ contains potentially useful information, and how would they even know where to look…?
As a Business Analyst, Technology Consultant or in any role where you need to identify suitable Applications, when trying to find a Solution or Product to meet your Requirements, particularly a Customised Off-The-Shelf (COTS) Product, you will no doubt come across blog posts, updates and group comments purporting to give you access to a ‘white paper’, ‘product review’ or ‘industry overview’…
These often turn out, frustratingly, to be nothing but a mechanism for gathering email addresses for the Sales & Marketing departments of various Vendors.
What’s worse is when you’re trickled into giving your contact details to gain some insight, only to discover all you’ve got access to is a product brochure.
One of the most common things I have to do on software development or Application selection projects, at one point or another, is to define a series of potential features or functions. They can range from obvious and nearly mandatory (e.g. ‘reset password’) to the more ‘out there’ features. Often, trying to get stakeholders to contribute to the production of these feature sets (note: they are not requirements yet!) is a pain in the proverbial backside. Everyone is too busy to tell you what they want their shiny new toy to do – although they’ll be quick enough to tell you if you get it wrong!
So, over many years & many projects, I have developed (and continue to develop) a quick and easy process to get the obvious features into a list early in the engagement _ but in a way that cries out for stakeholders to get stuck in and evolve it. Feel free to adapt it to your needs – you can use it to impress stakeholders with your speed of delivery!