We have covered most of the core items that should be consider when performing an Oracle database audit in previous posts, however there a number of other items that I would typically look into.

Database Links
A database link is an object in one database that allows a user access objects on another database. Once a database link has been created it can be used to access tables and views on the other database.

Database links are described in the view DBA_DB_LINKS.  A description of the fields in this view can be seen at
http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_1039.htm#i1576247

You should ensure that the owner of the database link is not PUBLIC.  If it is any user that connects to your database can connect to the second database. Furthermore, they connect to the second database with the user defined in username.  Where this is DBA, for example, a PUBLIC user could be accessing one of your databases as DBA.

Also prior to Oracle 10.2 the Sys.link$ view displays the password to the remote system in the clear.  The issue is explained in Oracle note 202987.1.  A copy of it can be seen here  
http://lefterhs.blogspot.com/2009/04/syslink-shows-all-database-link.html

Both of the above issues are explained by Pete Finnigan here
http://www.petefinnigan.com/forum/yabb/YaBB.cgi?board=ora_sec;action=display;num=1277288237

The view V$version displays the version numbers of core library components in the Oracle Database.  A description of the fields in this view can be seen at http://docs.oracle.com/cd/B19306_01/server.102/b14237/dynviews_2176.htm#sthref2821

You should ensure that (a) the Oracle database is still supported (see http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf) and (b) that the version installed meets the policies of the company you are auditing.

Dba_registry_history displays information about upgrades and critical patch updates.  A description of the fields in this view can be seen at http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_4057.htm#sthref1788

You should ensure that the database you are auditing has the latest critical patch installed or that they meet the requirements of the company you are auditing.

V$pwfile_users lists users who have been granted Sysdba and Sysoper privileges as derived from the password file.  A description of the fields in this view can be seen at http://docs.oracle.com/cd/B19306_01/server.102/b14237/dynviews_2032.htm#sthref2653

These users can connect to the database as Sysdba and/or Sysoper without providing a password (it is in the password file).  Ensure that these users match the policy in the company you are auditing.

Dba_jobs describes all jobs in the database.  A description of the fields in this view can be seen at http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_1086.htm#i1580430

Review to ensure that the jobs are appropriate.  Question their purpose.

Dba_triggers describes all triggers in the database.  A description of the fields in this view can be seen at http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_2107.htm#i1592586

Database triggers are described in detail here http://docs.oracle.com/cd/B19306_01/server.102/b14220/triggers.htm.  Basically Oracle allows you to define procedures that are executed when an INSERT, UPDATE, or DELETE statement is issued against the associated table.  Triggers have many uses but are often used to audit changes to data (e.g. capture the before and after images).  This is why they should be reviewed.  Review the triggers for the tables owner(s) you are interested in.  Discuss their purpose with the DBA.