While I admire the intent here, in the world at large it seems that multinationals and governments fail at this one with monotonous regularity and Blanche's final line - 'Whoever you are, I have always depended on the kindness of strangers', has been adopted by the computer security industry as the unofficial motto.
Of corse not. What will happen instead is that behind a consent box a lengthy disclaimer will ask consent for every piece of information and blanket every length of scope, triggering a cascade across providers and contractors.
And this is the reason: https://www.paypal.com/ie/webapps/mpp/ua/third-parties-list
This might help:
Of course they need to share data with payment providers (like a bank), or else they won't be able to get or deposit your money.
Of course they need to share data with auditing firms, or else they won't be able to do business in certain countries.
Of course they need to provide customer service.
Of course they need to check for fraud.
etc.
What do you expect Paypal to do in those cases?
Consent is mostly relevant to all the marketing and customer analysis activities, which aren't essential to the service, so can be refused, and would be severely curtailed as users stop consenting to these uses of their data.
They are already profiting from the service they provide but they still give (Sell! I bet they can use a different terminology but essentially this is it) the users data to other companies.
Those are the companies that brought GDPR on all of us, and those are the parties that should be punished with 4% global revenue, multiple times.
I bet everyone will be shocked what the companies are doing with our data, from our banks, credit card companies, insurance companies,... i think that everyone (or most) will stop complaining about GDPR and want it for their country too.
Just an example, what gets delivered just for Facebook: "Advertising ID and device ID to segment user groups based on app behaviour, encrypted e-mail address associated with PayPal users (without indicating account relationship), IP Address, Anonymous ID generated by cookies, pixel tags or similar technologies embedded in webpages, ads and emails delivered to users. Mobile advertiser ID, IP Address and other metadata via Facebook SDK in mobile apps."
Encrypted e-mail address? Why encrypted, not hashed? IP? Why the FB needs my IP on connecting to paypal? And the list goes on and on. If GDPR will stop this the whole world will benefit.
If you have the same use case of private data but have technical changes (i.e. a different subcontractor handling the processing) then you do not need a new consent.
If you have a new use case, then yes, you get to use only the data of those users who agree to it. Which will not be all users anyway, as consent must be freely given, i.e. with an opportunity to refuse consent but keep the service.
The expected result of "a consent box a lengthy disclaimer will ask consent for every piece of information and blanket every length of scope" would be the TL;DR reaction - since all of that must be opt-in, the user would just click "Continue", keeping the default settings that don't give you any consent.
That is not how some are reading it. It's not how I've understood Article 28(2) either, though getting new consent each time is nuts (e.g. I change from Mailgun to Postmark and have to ask all SaaS customers for consent).
Some discussions: https://seqlegal.com/blog/article-28-gdpr-problems-processor... https://seqlegal.com/blog/gdpr-sub-processors-and-authorisat...
If a company legally holding private data (i.e. a controller) gets a different subcontractor (a processor), they do not need new consent from the user; and the controller is still fully responsible for the data privacy.
In your example, you're a processor who operates the data with controller's authorization (let's avoid the word "consent"; this is a quite specific term in context of GDPR with a different meaning) - and they are responsible for ensuring that you will safeguard this data properly, so they can't transfer data to you if they don't have solid guarantees about what you'll do and not do with the data they're responsible for.
And the particular situation seems reasonable to me. You do not need to ask all SaaS customers for some action; as your links directly quote ".. or general written authorisation of the controller" i.e. your agreement can specify (if your customers are okay with that) that you're allowed to use other processors and change them. You do have to inform them about such changes (just as you informed them about the current subcontractors touching their data before they signed up, right?). If you change from Mailgun to Postmark, all you have to do is to send a notification to all your SaaS customers, and nobody is going to cancel over that. On the other hand, if you change from Mailgun to NigerianPrinceMailings Inc., then they might reasonably want to decline, so that's why the notification is required.
This makes sense from the user's perspective. Maybe they trust Mailgun but do not trust Postmark. If they have explicitly agreed to you sharing their personal data with one company you shouldn't be able to start sending that customer's personal data to another company without their consent.
If you sign up for my service and I ask for consent to send specific data to SecuriCo for "user analytics and tracking" I shouldn't be able to change that to sending the data to the NSA without telling you. The whole point is that the user should be in control of what businesses are doing with their personal information.
Either they have the organizational capacity to handle private information properly, or they should not do it at all.
There's no reason for every company to get a data processing agreement with every SaaS they use as long as they're not putting private data of other people inside; and in most cases (except CRM and payment systems) they should not do so. There's no reason for every random company to get a data processing agreement with the contractor maintaining their WordPress site if that site doesn't contain any private information, and it probably should not. On the other hand, if it does, then giving full access to that data should be more difficult than simply giving the keys to a random contractor; the company is fully responsible for whatever you do ("Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject."), so that includes vetting you, being able to supervise what you've done, and probably some liability requirement. On the other hand, if that's a standard service you're providing, it all means that your standard agreement form just needs a few extra paragraphs to cover that data processing part.
The log/IP address issue has technical solutions - you can use logrotate in combination with gnupg to ensure that logs are available if you need to analyze them, but are encrypted and not available to everyone logging on that server.