October 18, 2017 at 8:42 pm
We had our first CoBIT audit. From the sql side I can only say the auditors want us to have policies, e.g. password expiration and complexity, and also prove that the policies were actually implemented. They also wanted to know all sql users created or deleted in the last year, the actual create\delete request, and what proof we have that done the tasks. BTW: For us, they did not provide any examples showing exactly what they are looking for.
My problem is not so much meeting their requests (which I think are often reasonable) but other than Excel, maybe SharePoint, or a database table as an IT person I have no way to capture the flood of new documentation that will be required to document these tasks. And capturing is not the full story. I need to be able to retrieve answers to their questions from the data at least twice a year when they revisit us.
How do you manage all the CoBit (HIPPA, etc.) information you are now required to keep for audits?
TIA,
edm2
October 19, 2017 at 4:02 pm
Barkingdog - Wednesday, October 18, 2017 8:42 PMWe had our first CoBIT audit. From the sql side I can only say the auditors want us to have policies, e.g. password expiration and complexity, and also prove that the policies were actually implemented. They also wanted to know all sql users created or deleted in the last year, the actual create\delete request, and what proof we have that done the tasks. BTW: For us, they did not provide any examples showing exactly what they are looking for.My problem is not so much meeting their requests (which I think are often reasonable) but other than Excel, maybe SharePoint, or a database table as an IT person I have no way to capture the flood of new documentation that will be required to document these tasks. And capturing is not the full story. I need to be able to retrieve answers to their questions from the data at least twice a year when they revisit us.
How do you manage all the CoBit (HIPPA, etc.) information you are now required to keep for audits?
TIA,
edm2
It's going to be different for everyone depending on the company, available resources, etc.
Most places I've been at use some type of change control processes and some kind of ticketing software and we would rely on those for a lot of the auditing documentation.
We never made any changes in production without the tickets and having everything go through change control. That can be the documentation. If the DBA implementing the changes has to sign off on the ticket indicated what work was done, when it was completed, etc then that can be the proof of this getting done. If SQL Server users needed to be added or deleted, it went through the change control process, ticketing system. Password changes for the service accounts went through the same thing. If someone needed access to some more secure database for some business reason, that was all done through that process - when the elevation was enabled, how it was monitored and when it was disabled. You can get a pretty good set of documentation for audits by using those types of programs, processes.
Sue
October 19, 2017 at 4:19 pm
Insane --
That seems like a practical approach! A ticketing system.
We just need the courage and persistence to tell everyone we need a ticket for stuff that used to be done by an email or as part of project..
edm2
October 19, 2017 at 4:29 pm
Barkingdog - Thursday, October 19, 2017 4:19 PMInsane --That seems like a practical approach! A ticketing system.
We just need the courage and persistence to tell everyone we need a ticket for stuff that used to be done by an email or as part of project..
edm2
Yup...but they get used to it. Just don't do anything without a ticket. The positive that comes with that is when you say "Sure I'll take care of that when I have a ticket" or "Please open a ticket so I can do that for you"...sometimes no ticket ever comes and they no longer "need" whatever it was. So another task off your plate 🙂
Sue
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply