You should not (and cannot successfully) admin lock DDIC.
You can reschedule the basis jobs to run under a different step user though to reduce its authorization requirements, but you cannot remove all access or lock it (which amounts to the same).
DDIC is used to perform certain "after import" events in the CTS which activate certain objects, or depending on how the transport is crafted certain function modules will even run as DDIC even if a different user triggered the import or called the RFC which triggered the generation.
You can lock it if you want to prove me wrong, but you will get a bloody nose from it - 100% guaranteed... :-)
If you are interested, I will post a blog or wiki on the minimum authorizations required by user DDIC so that you can cover what is definitely needed. I have not done it until now, as SAP has been removing some of the hardcoding which has reduced the authorization requirements and also the requirement to know DDIC's password to be able to run some programs as yourself (assumption = if you know DDIC's password, then you could also have run it as DDIC anyway...),but that seems to be stable now on 7.31 systems.
Regarding the audit log: those are the function modules which DDIC needs. Either your basis folks are transporting as DDIC or you have DDIC in RFC connections (very bad idea but not uncommon) or you have set parameter auth/rfc_authority_check to 2 or higher (which recognizes an internal call with the same strictness as an external call)... or all 3 of above, which is causing this "noise".
You must be very careful when making changes in this area as it touches organizational and technical issues which are very deep in the system.
Cheers,
Julius