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.