Auditing IRM Protected Documents

A colleague has been asking for some information about IRM auditing, so I thought I'd turn the response into a blog entry for the benefit of all. (Update: some recent customer engagements have prompted me to revisit this entry and add further information.)

To summarise, a critical element of the Oracle IRM solution is the insight it provides into the usage of your sensitive information assets - even while they are being used by external users.

The IRM Desktop can create audit records for a number of activities including:

  • Open a file

  • Print to a printer

  • Print to file

  • Seal a file

  • Save changes to a file (reseal)

  • Fail to open a file due to access denial

I provide a view below of an 11g audit trail showing several of the above types of record.


In normal configuration, the audit records are cached by the IRM Desktop until its next communication with the server. This communication is usually a Synchronise event according to a schedule defined on the server - typically a daily event - but any communication with the server will be used to upload cached audit records.

For example, a new user will always make a rights request for the first file they open. Once that has happened, the user will have cached rights that mean subsequent file accesses won't necessarily involve a server connection - so auditable operations will be cached and uploaded later.

This scheduled upload model is deliberately designed to reduce server traffic for large deployments. If every auditable action was uploaded to the server instantly, this would generate lots of communications for questionable benefit - it suggests that someone is watching the audits in real-time. For most practical purposes, a daily upload is perfectly adequate. In any case, so much usage occurs offline that instant upload is impractical.

If you want audits to be uploaded more frequently, then you can define a more frequent synching schedule, or modify the offline periods of some or all roles to promote more frequent server communication.

In terms of differentiation from rival solutions, Oracle IRM offers a number of advantages:

  • Some solutions only generate audit records when the user explicitly connects to the server to request rights. If the user is authorised for offline access - perhaps for a week or a month - the activity during that period is not audited at all.
  • Some solutions provide no audit trail for significant operations such as editing and printing. You get periodic indications of who is using your content, but no insight as to how it is being used. Printing, for example, obviously involves the creation of an unprotected hardcopy of a document - which is an activity you may well want to be aware of and be able to track back to the relevant users.
  • Oracle IRM provides role-based control over auditing. That is, rather than audit all users for all activities, you can select which roles need to be audited. I've come across several real-world scenarios where customers deliberately disable auditing for particular roles:

    • Some customers want auditing for their most sensitive information, but are not so concerned for less sensitive classifications. As long as the less sensitive information is protected, an audit trail is sometimes regarded as overkill. This may be especially true where the less sensitive information is accessible to thousands of users who would generate substantial amounts of audit data.

    • Some customers want auditing for 3rd party users and contractors or temporary staff, but are not so concerned about auditing permanent employees.

    • Some customers specifically disable auditing for board members for legal reasons. They prefer not to have a blow-by-blow account of which board members have seen which documents. At the same time, they do audit any 3rd party advisors with whom board communications might be shared.

    • Some customers disable auditing if there is a concern about privacy implications according to local law. (As an aside, IRM 11g prompts all new users to accept your privacy policy as a precondition of service use, and enables you to provide a link to that policy.)

  • Most solutions expose all audit records to anyone with the admin rights to run audit reports. Oracle IRM's classification model enables us to filter audit reports automatically, so the person responsible for a particular classification will only see audit records relating to that classification. This is an important aspect of the Segregation of Duties. If an audit report exposes activity in someone else's classifications, that in itself may be an unwelcome exposure of information. For example, in Oracle's in-house deployment we use IRM to protect acquisition projects, but when I access the admin console I see no trace of that activity or even of those classifications because they are none of my business.

  • Some solutions provide a very technical audit trail that only makes sense if you understand certificates and licenses. Oracle IRM, as shown above, provides business-friendly audit reports that simply summarise who has been using what, when, where, and how. One of the goals of Oracle IRM is to enable rights management to be delegated to business information owners, so providing business-friendly audits is crucial.

The following image illustrates how auditing is role-based (in this case for a role called Contributor), making it easy to enable and disable for different roles for different classifications.


So, to summarise, Oracle IRM provides comprehensive, business-friendly auditing of significant interactions with sealed content - both online and offline. The audit trail is uploaded regularly according to a schedule, and can be enabled and disabled by role, as required.


Post a Comment:
  • HTML Syntax: NOT allowed

Oracle IRM protects and tracks your sensitive information no matter where it goes. It combines business friendly encryption with role based usage rights and auditing.

11g quick guide


« July 2016