In the past I performed the function of an auditor. (for legal reasons, I cannot call myself an auditor, but the fundamental function of an auditor is to compare expected behavior with actual behavior, and that's what I did). @Iszi is correct that different institutions will have different understandings of RACI. If I were an auditor visiting your facility the first finding would be that your management hasn't described that responsibility matrix. In traditional auditing, one does not hold people responsible where there is no policy. (Modern risk based auditing can operate a bit differently, but I think that's outside the scope of this question).
Based on the evidence presented, I believe you are correct. The procedural document should describe the procedure for system auditing, including the events to be audited, and the procedure for reviewing the audit logs. If the goal is merely to comply with an audit regime, that is sufficient.
If the goal is to improve security, reduce the organization's exposure to risk, decrease the number of incidents and decrease the damage done in any individual incident, then your organization needs to go further. Your system audit procedures are based on assumptions about the assets your protecting, and the threats to that asset. Threats and assets change more frequently than eventid's. Your management should have a mechanism to update the audit procedures. Audit review is not an end; it is a tool to reduce risk, reduce incident frequency and severity. Management should establish a periodic review of audit activities and to adjust those audit activities to better support the organization's business goals.
(I recognize that I've used the term "audit" in two contexts, and that it could be confusing. I'm assuming that you are writing procedures for capturing and analyzing system event logs (system audit). This is separate from external audit and review, which might be called independent audit)
As @Iszi says, each organziation will differ, but I believe that in the general case:
System Aministrators/SOC staff are responsible for daily/continuous review of audit logs as described in the procedural document you're writing.
System Owners/System Management is Accountable for the results of audit (generally measured as the time to detect an incident, the % of incidents detected on internal vs external evidence, and the average time to resolve an incident). Management is also responsible and accountable for managing the audit process, which includes ensuring that the audit procedures are updated to match business needs.
This gets a little more complicated if we outsource security monitoring to a SOC; the system manager/owner should still be accountable, but they have delegated responsibility. If I were reviewing such an arrangement, I'd look for an SLA for Security that included the RACI you're looking for.
