SOX Adminis Manual

Sarbanes-Oxley
Express
Administrators Manual - August 2005
OpenPages, Inc.
201 Jones Road
Waltham, MA 02451
781.647.3800
www.openpages.com
ii
Copyright Information
Copyright 2003-2005 OpenPages, Inc. All rights reserved.
No part of this book may be reproduced, stored in a retrieval system, or transmitted by any
means, electronic, mechanical, photocopying, recording, or otherwise, without written
permission from OpenPages.
All questions pertaining to duplication or redistribution of this material and/or the software that
it describes should be directed to:
OpenPages, Inc.
201 Jones Road
Waltham, MA 02451
781.647.3800
Trademark Information
OpenPages, Sarbanes-Oxley Express, and SOX Express are Registered Trademarks of
OpenPages Inc.
Disclaimer
Although every precaution has been taken in the preparation of this user manual, OpenPages
and the author assume no responsibility for errors or omissions. No liability is assumed for
damages resulting from the use of the information contained herein.
Release Information
Software Version: Sarbanes-Oxley Express 3.1.0
Administrators Manual Published: August 2005
Manual Version: AM-310.7
iii
Table of Contents
Chapter 1
Introduction
What is the Sarbanes-Oxley Act of 2002? . . . . . . . . . . . . . . . . . . . . . . 2
Overview . . . . . . . . . . .
What is Section 302? . . .
What is Section 404? . . .
Additional Responsibilities
Additional Information . .
....
....
....
...
....
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
2
2
What is Sarbanes-Oxley Express? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How Can Sarbanes-Oxley Express Help Me? . . . . . . . . . . . . . . . 3
What is Internal Controls Documentation? . . . . . . . . . . . . . . . . 3
Chapter 2
Administering SOX Express

Administering Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
About SOX Express Users and Groups . . . . . .
About User Names and Passwords . . .
Creating a New SOX Express User . . . . . . . . .
Modifying an Existing User Account . . . . . . . .
Disabling a User Account . . . . . . . . . . . . . . .
Re-enabling a SOX Express User . . . . . . . . . .
Associating an Existing User with a Group . . .
Disassociating a User from a Group . . . . . . . .
Creating a Group . . . . . . . . . . . . . . . . . . . . .
Removing a Sub-Group . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
7
7
8
8
8
9
Using Application Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Overview of the SOX Express Application Permissions
SOX Express Application Permissions . . . . . . . . . . . .
Administration . . . . . . . . . . . . . . . . . . . . . .
Audit Trail . . . . . . . . . . . . . . . . . . . . . . . . .
Browse Files . . . . . . . . . . . . . . . . . . . . . . .
Folders . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Management . . . . . . . . . . . . . . . . . .
View Locks . . . . . . . . . . . . . . . . . . . . . . . .
Other Permissions . . . . . . . . . . . . . . . . . . . . . . . . .
All Permissions . . . . . . . . . . . . . . . . . . . . . .
Administration . . . . . . . . . . . . . . . . . . . . . .
Collaboration . . . . . . . . . . . . . . . . . . . . . . .
Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
10
11
11
11
11
11
11
11
11
12
iv
Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Setting Up Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Overview of Implementing ACL Security . . . . . . . . . . .
About Access Controls . . . . . . . . . . . . . . . . .
Preparing For Your Security Implementation . .
The Compliance Object Folder Structure . . . . . . . . . . .
Using Inheritance with Access Control Lists . . . . . . . .
About Breaking Inheritance . . . . . . . . . . . . . .
Creating a New ACL . . . . . . . . . . . . . . . . . . . . . . . . .
Editing an Existing ACL . . . . . . . . . . . . . . . . . . . . . .
Deleting an Existing ACL . . . . . . . . . . . . . . . . . . . . .
Using Groups to Establish User Roles . . . . . . . . . . . . .
The Core SOX Express Groups . . . . . . . . . .
Example: Using Groups to Establish User Roles
Using Groups to Limit User Activities . . . . . . . . . . . . .
Using Nested Groups to Limit User Scope . . . . . . . . . .
Step One: Breaking Folder Inheritance . . . . . .
Step Two: Nesting Your User Groups . . . . . . .
Using Group ACLs to Traverse Business Entities . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
15
16
16
17
18
18
19
19
19
20
23
23
23
26
Setting Up LDAP User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 27

Overview of LDAP Authentication . . . . . . . . . . . . . . . . . . . . .
Supported LDAP Servers . . . . . . . . . . . . . . . . . . . . . .
Configuring the LDAP Authentication Module . . . . . . . . . . . . . .
Step One: Adding Existing Users to the LDAP Server . .
Step Two: Changing the OPSystem Password (optional)
Step Three: Editing the LDAP Configuration File . . . . . .
.
.
.
.
.
.
27
27
27
27
28
28
Configuring Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
About the UPEA Command File . . . . . . . . . . .
Pre-requisites . . . . . . . . . . . . . . . . .
UPEA Syntax . . . . . . . . . . . . . . . . . .
Changing the Password Encryption Algorithms
Changing the 3DES Encryption Key . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
30
31
32
Working with Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supplied Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding Reports . . . . . . . . . . . . . . . . . . . . . . . .
Accessing the Report Pages and Page Templates
Creating a New Instance of a Report . . . . . . . . . . . . . .
Modifying an Existing Report Template . . . . . . . . . . . . .
Deleting a Report . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Interactive Reports . . . . . . . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating an Interactive Report . . . . . . . . . . . . .
Running an Interactive Report . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
34
36
36
37
38
38
38
38
38
39
Limiting the Report Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

About the Report Scoping Wizard . . . .
Overview . . . . . . . . . . . . . . . .
Usage Example . . . . . . . . . . .
Configuring the Report Scoping Wizard
Overview . . . . . . . . . . . . . . . .
Configuring the Scope Wizard .
Using the Report Scoping Wizard . . . . .
Overview . . . . . . . . . . . . . . . .
Scoping a Report . . . . . . . . . .
Table of Contents
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
40
40
40
41
41
42
Managing Reporting Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Overview of Reporting Periods . . . . . . . . . . . . . . . . . . . .
Creating a New Reporting Period . . . . . . . . . . . . . . . . . . .
Changing the Reporting Period Naming Convention
Deleting a Reporting Period . . . . . . . . . . . . . . . . . . . . . .
Deleting a Reporting Period . . . . . . . . . . . . . . . . .
Configuring the Deletion Period . . . . . . . . . . . . . .
Accessing Past Reporting Periods . . . . . . . . . . . . . . . . . .
How ACLs and Reporting Periods Interact . . . . . . .
How Reporting Periods and Audit Trails Interact . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
44
44
44
45
45
45
Resetting Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Overview of Compliance Object Resetting . . . . . . . .
Preparing Your Data . . . . . . . . . . . . . . . . . . . . . .
Backing Up Your SOX Express Data . . . . . .
Creating a Reporting Period (optional) . . . .
Creating a Ruleset . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Ruleset File . . . . . . . . . . . . . .
Sample Ruleset . . . . . . . . . . . . . . . . . . . .
The Ruleset Tag Library . . . . . . . . . . . . . .
Loading the Ruleset . . . . . . . . . . . . . . . . . . . . . . .
Performing the Compliance Object Reset . . . . . . . .
Preparing for the Reset . . . . . . . . . . . . . . .
Configuring the Ruleset Parameters . . . . . .
Using the Compliance Object Reset Page . .
Starting the Compliance Object Reset . . . . .
Viewing the Reset Status . . . . . . . . . . . . .
Viewing the Reset Session Details . . . . . . . . . . . . .
Viewing the Reset Session Log . . . . . . . . . .
After the Reset . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
46
46
47
47
47
48
55
55
55
55
56
57
57
57
58
58
Starting Jobs from SOX Express Objects . . . . . . . . . . . . . . . . . . . . . . . 59

Overview of SOX Express Jobs . . . . . . . . . . . . . . . .
Additional Information . . . . . . . . . . . . . . . .
Starting a Job from a SOX Express Compliance Object
Monitoring Job Progess . . . . . . . . . . . . . . . . . . . . .
Chapter 3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
59
Configuring SOX Express

Using The Backup Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Overview of the Backup Utility . . . . .
Prerequisites . . . . . . . . . . . . . . . . . .
Configuring the Backup/Restore Utility
Using the Backup Utility . . . . . . . . . .
Additional Information . . . . . . . . . . .
Generated Files . . . . . . . . . .
Usage Notes . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
61
61
61
62
Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Overview of the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . 63
Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Generating Object Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Overview of Name Generation . . . .
Modifying the Naming Settings . . . .
Configuring the Object Name . . . . .
Autogenerating Long Names
Naming Examples . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
65
65
66
Managing Signatures and Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Overview of Signatures and Locks . . . . .
Enabling and Disabling Signatures . . . . .
Manual Signatures . . . . . . . . . .
Automatic Signatures . . . . . . . .
Cascading Signatures . . . . . . . .
Enabling and Disabling Locks . . . . . . . .
The Lock and Unlock Permissions . . . . .
Locking Access Privileges . . . . . . . . . . .
....
....
....
....
....
....
....
....
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
67
67
68
69
69
70
70
Enabling Workflows for SOX Express Objects . . . . . . . . . . . . . . . . . . . . 71

About Enabling SOX Express Workflows . . . . . . . . . . . . . . . . . . 71
Pre-requisites for Starting SOX Express Jobs . . . . . . . . . 71
Enabling a Job Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Configuring Job Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Overview of SOX Express Jobs . . . . . . . . . . . . . . . . . .
Enabling Signatures for SOX Express Jobs . . . . . . . . . .
Assigning Job Tasks Based on Object Properties . . . . . .
Planning Ahead . . . . . . . . . . . . . . . . . . . . . . .
Modifying the Job Type Properties . . . . . . . . . .
Modifying the Job Task . . . . . . . . . . . . . . . . . .
Creating the Compliance Object Custom Property
Attaching Reports to Workflow Tasks . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a Report to a Workflow Task . . . . . . . . .
Removing a Report from a Workflow Task . . . . .
Using Interactive Reports with Workflow Tasks .
Enabling Optional Reporting Tools
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73
73
73
73
73
74
75
75
75
75
76
76
. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Differences From the Exporter Tool . . . . . . . . . . . . .
Configuring the Reporting Metadata . . . . . . . . . . . . . . . . . . .
About the Configuration Tables . . . . . . . . . . . . . . . .
About the Reporting Schema Scripts . . . . . . . . . . . .
Customizing the Reporting Schema Configuration . . .
Supported Macro Keywords . . . . . . . . . . . . . . . . . . .
Populating the Reporting Schema . . . . . . . . . . . . . . . . . . . .
Checking the Results of the Reporting Schema Refresh
Exporting Data to the Reporting Database Instance . . . . . . . .
Exporting the Reporting Schema Contents . . . . . . . .
Importing the Reporting Schema Contents . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
77
77
77
79
79
80
81
82
83
83
84
Changing the Database Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Overview of Changing the Database Passwords . . . . . . . . .
Changing the Oracle Password . . . . . . . . . . . . . . . . . . . .
Changing the WebLogic Password . . . . . . . . . . . . . . . . . .
Changing the Password in WebLogic . . . . . . . . . . .
Changing the Password References in SOX Express
Changing Your Server IP Address . . . . . . . . . . . . . . . . . .
Chapter 4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
85
86
86
86
87
Modifying SOX Express Behavior

Customizing the Overview Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
About Customizing the Overview Pages . . . . .
Modifying the Overview Page Definitions . . . .
Enabling/Disabling the Expand All Capability
Modifying the Overview Node Cache . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
90
91
Modifying Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Overview of Modifying Compliance Objects . . . . . . . . . . . . . . . .

Example: Adding a New Text Field . . . . . . . . . . . . . . . .
Step One: Identifying the New Field . . . . . . . . . . . . . . . . . . . .
Example: Identifying the New Field . . . . . . . . . . . . . . .
Step Two: Defining the Field Properties . . . . . . . . . . . . . . . . . .
Example: Defining the Field Properties . . . . . . . . . . . . .
Step Three: Attaching the Property Bundle . . . . . . . . . . . . . . . .
Example: Attaching the Property Bundle . . . . . . . . . . . .
Step Four: Displaying the New Field . . . . . . . . . . . . . . . . . . . .
Example: Displaying the New Text Field . . . . . . . . . . . .
Step Five: Activating the New Field . . . . . . . . . . . . . . . . . . . . .
Example: Adding a New Text Area Field . . . . . . . . . . . . . . . . . .
Example: Adding a New Drop-down Selection Field . . . . . . . . . .
Example: Adding a New HTML Field . . . . . . . . . . . . . . . . . . . . .
Hiding an Existing Object Property Field . . . . . . . . . . . . . . . . . .
Modifying Property Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modifying an Existing Property in configTileDefinitions.xml
Modifying an Non-Existent Property in
configTileDefinitions.xml . . . . . . . . . . . . . . . . . . . .
Modifying the Overview Label . . . . . . . . . . . . . . . . . . .
92
92
92
93
93
95
96
96
97
98
99
99
101
103
105
106
106
107
107
Additional Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Compliance Object Tables . . . . . . . . . . . . . . . .
Adding a Column to a Compliance Object Table . . . . . . .
Replacing a Column in a Compliance Object Table . . . . .
Modifying the Label of a Compliance Object Table Column
Hiding a Column in a Compliance Object Table . . . . . . .
Configuring the Compliance Object Listings . . . . . . . . . . . . . . .
Adding a Column to a Compliance Object Listing . . . . . .
Replacing a Column in a Compliance Object Listing . . . .
Modifying the Label of a Compliance Object
Listing Column . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hiding a Column in a Compliance Object Listing . . . . . . .
Configuring the User Selector Tool . . . . . . . . . . . . . . . . . . . . . .
Configuring the User Segment Size . . . . . . . . . . . . . . .
Specifying a Group for the User Selector . . . . . . . . . . . .
Configuring the Displayed Fields . . . . . . . . . . . . . . . . .
Redirecting the SOX Express Logout Link . . . . . . . . . . . . . . . . .
Displaying the Sub-Processes Header in the Action Menu . . . . .
Resolving Duplicate Names During Copy Operations . . . . . . . . .
Setting the Default Copy Behavior . . . . . . . . . . . . . . . .
Copy Behavior Options . . . . . . . . . . . . . . . . . . . . . . . .
Using an SSL Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
108
108
108
109
110
111
111
111
112
113
114
114
114
115
115
116
117
117
117
117
118
Using Netegrity SiteMinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Overview of SiteMinder Integration . . . . . . . . . . . . . . .
Installing and Configuring SiteMinder . . . . . . . . . . . . . .
Configuring SOX Express for SiteMinder Integration . . .
Configuring OpenPages for SiteMinder Integration . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
119
119
119
Appendix A
The Notification Manager

Overview of the Notification Manager . . . . . . . . . . . . . . . . . . . . 120
Why would I use Notifications? . . . . . . . . . . . . . . . . . . 120
About the Notification Manager
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Exploring the Notification Reports . . . . . . . . . . . .

Using the Notification Manager . . . . . . . . . . . . . .
Requirements for Setting Up a Notification
Results of Running a Notification Report . .
Step One: Preparing Your Data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
121
121
121
121
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using the Test Notification Template . . . . . . . . . . . . . . . . . . . . 122
Using the General SOX Notifications Template . . . . . . . . . . . . . 122
Step Two: Creating the Notification
. . . . . . . . . . . . . . . . . . . . . . . . . . 123
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Test Notification . . . . . . . . . . . . . . .
Understanding the Test Notification Fields
Creating a General Notification . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
123
123
123
126
Step Three: Triggering the Notification . . . . . . . . . . . . . . . . . . . . . . . . 129

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running Notification Reports Manually . . . . . . .
Running Notification Reports Automatically . . . .
The Notification Manager Command Line
Scheduling Your Automatic Notification
Chapter B
.......
.......
.......
Interface
.......
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
129
129
129
129
131
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
132
133
133
135
137
139
140
142
144
147
151
153
155
157
159
160
161
162
164
164
164
165
165
166
166
167
167
167
167
168
168
168
The SOX Express Reporting Schema

Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
Compliance Object Tables . . . . . . . . . . . . . .
Business Entity . . . . . . . . . . . . . . . .
Accounts . . . . . . . . . . . . . . . . . . . . .
Sub-Accounts . . . . . . . . . . . . . . . . .
Processes . . . . . . . . . . . . . . . . . . . .
Sub-Processes . . . . . . . . . . . . . . . . .
Control Objectives . . . . . . . . . . . . . .
Risk . . . . . . . . . . . . . . . . . . . . . . . .
Controls . . . . . . . . . . . . . . . . . . . . .
Test . . . . . . . . . . . . . . . . . . . . . . . .
Test Results . . . . . . . . . . . . . . . . . . .
Issues . . . . . . . . . . . . . . . . . . . . . . .
Action Items . . . . . . . . . . . . . . . . . .
Signatures . . . . . . . . . . . . . . . . . . . .
Files . . . . . . . . . . . . . . . . . . . . . . . .
Links . . . . . . . . . . . . . . . . . . . . . . .
Milestones . . . . . . . . . . . . . . . . . . . .
Compliance Object Relationship Tables . . . . .
Business Entity Relationships . . . . . . .
Account Relationships . . . . . . . . . . . .
Sub-Account Relationships . . . . . . . .
Process Relationships . . . . . . . . . . . .
Sub-Process Relationships . . . . . . . . .
Control Objective Relationships . . . . .
Control Relationships . . . . . . . . . . . .
Test Relationships . . . . . . . . . . . . . .
Test Result Relationships . . . . . . . . .
Issue Relationships . . . . . . . . . . . . . .
Test Result Relationships . . . . . . . . .
Action Item Relationships . . . . . . . . .
Milestone Relationships . . . . . . . . . . .
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
....
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Master Relationships Table . . .

Milestone Relationships
Security Tables . . . . . . . . . . .
Effective Rights . . . . .
Folders . . . . . . . . . . .
Actors . . . . . . . . . . . .
Audit Trails . . . . . . . . . . . . . .
Audit Trail . . . . . . . . .
Appendix C
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
169
169
170
170
171
171
172
172
Integrating with TeamMate

What is TeamMate? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
How TeamMate and SOX Express Interact . . . . . . . . . . . . . . . . 173
TeamMate/SOX Express Naming Schemes . . . . . . . . . . 174
Exporting Data to TeamMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
How Exporting Data Works . . . . . . . . . .
Setting Up The Schema Mapping . . . . . .
Running the TeamMate Export Report . .
Importing the Data Into TeamMate . . . .
Troubleshooting the Export Process . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
175
175
175
175
176
Importing Data From TeamMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

How Importing Data Works . . . . . . . . . . .
Exporting the Data From TeamMate . . . . .
Transforming the XML File . . . . . . . . . . . .
Importing the TeamMate Data . . . . . . . . .
Displaying the TeamMate Properties
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
177
177
177
178
Introduction
This Administration Guide provides information and instructions for

maintaining and administrating the Sarbanes-Oxley Express
application. Topics covered include user and group administration,
database backup and restoration, customizing the applications look
and feel, using the data loader capabilities, and much more.
What is the Sarbanes-Oxley Act of 2002? 2
What is the Sarbanes-Oxley Act of 2002?

Overview
The Sarbanes-Oxley Act of 2002 (SOA) is a piece of landmark legislation designed to make
public companies more transparent in their financial reporting and more proactive in sharing
material information with other participants in the financial reporting chain such as auditors,
audit committees, analysts, and investors.
The SOA is a complex act with many provisions. The two sections most relevant to public
corporations are sections 302 and 404. Section 302 pertains to disclosure controls and
procedures; Section 404 to internal controls and procedures for financial reporting.
What is Section 302?

Section 302 of the SOA mandates that CEOs and CFOs personally certify financial statements
and filings, as well as affirm that they are responsible for establishing and enforcing disclosure
controls and procedures at all levels of their corporation. With each quarterly filing, they must
certify that they have evaluated the effectiveness of these controls. In addition, they must
disclose to their audit committee all significant deficiencies, material weaknesses, and acts of
fraud.
Section 302 of the Sarbanes-Oxley Act was put into effect in 2002.
What is Section 404?

Section 404 of the SOA requires an annual evaluation of internal controls and procedures for
financial reporting. Under this scheme, a corporation must document its existing controls that
have a bearing on financial reporting, test them for efficacy, and report on gaps and
deficiencies.
Furthermore, the companys independent auditor must issue a report, to be included in the
companys annual report, that attests to managements assertion on the effectiveness of
internal controls and procedures and financial reporting.
Section 404 of the Sarbanes-Oxley Act will be effective for the fiscal years ending June 15th,
2004.
Additional Responsibilities
The SOA also describes other responsibilities. For example, it informs company boards of their
responsibilities with respect to the institution of audit committees. It instructs the SEC to create
an independent public accounting oversight board with the express mandate to regulate the
conduct of audit firms. Furthermore, it lays down guidelines for conduct of attorneys that
represent public corporations before the SEC.
Additional Information
This guide only provides a high-level overview of the Sarbanes-Oxley Act of 2002. You can find
more in-depth information about the Sarbanes-Oxley Act of 2002 in the Sarbanes-Oxley
Resource Center on the OpenPages web site at http://www.openpages.com.
Introduction
What is Sarbanes-Oxley Express? 3
What is Sarbanes-Oxley Express?

Overview
Sarbanes-Oxley Express (SOX) is an Internal Controls Management System that empowers
CEOs, CFOs and financial management officers to document internal controls as set up by the
Sarbanes-Oxley Act.
SOX allows users to easily see the status of their internal controls documentation project, and
provides a secure repository for the storage of their IC documentation.
How Can Sarbanes-Oxley Express Help Me?

SOX has many features that assist users in documenting their internal controls. Some of the
most important are:
Collaborative Task Management

Allows the breakdown of the Internal Controls documentation project into easily
achievable milestones and tasks that can be assigned to specific users.
Automated Reporting Processes

Generates real-time reports on the current status of the IC documentation project that
can be sorted and filtered on multiple levels.
Internal Controls Documentation Repository

Flexible, robust documentation repository with versioning and both property and fulltext searching capabilities.
Signoff Capability
Supports the attachment of signoff tasks that require a user to append a signature to
a compliance object.
What is Internal Controls Documentation?

A critical facet of implementing an internal controls framework is developing a repository of
internal controls. Internal controls may relate to different aspects of running the business,
particularly financial reporting, optimal operations, and compliance.
For each financial account, a business will have one or more processes that apply to that
account. Each process has certain risks associated with it that may result in an unwanted
result, such as fraud, mishandling of funds, or simple accounting errors. The Sarbanes-Oxley
Act of 2002 requires that these risks be identified, and that controls be put into place to prevent
errors from occurring. The existence and performance of these controls must be documented
and evaluated by the CEO and CFO of the company, and attested to by an external auditor.
Introduction
Administering
SOX Express
This chapter provides information about administering the SOX Express
application using the capabilities of the SOX Express user interface,
including adding and modifying SOX Express users, setting up folderlevel security, report administration, and managing reporting periods.
This chapter contains the following sections:
Administering Users and Groups on page 6

Using Application Permissions on page 10
Setting Up Security on page 13
Setting Up LDAP User Authentication on page 27
Configuring Password Encryption on page 30
Working with Reports on page 33
Managing Reporting Periods on page 43
Resetting Compliance Objects on page 46
Starting Jobs from SOX Express Objects on page 59
Administering Users and Groups 6
Administering Users and Groups

About SOX Express Users and Groups
To create and administer users and groups for Sarbanes-Oxley Express, you must have access
to a SOX Express user account with administrative privileges.
In general, there are two different groups of SOX Express users; regular SOX Express users
who can view and create compliance objects (such as accounts, processes, risks, etc.), and
SOX Express administrators, who can create and modify users and groups, as well as other
administrative features of the SOX Express application.
This section will explain how to create, modify, and delete SOX Express user accounts and
groups using the SOX Express interface.
About User Names and Passwords

When creating user names, the following rules apply:
The maximum length of a user name is 32 characters.

The user name cannot contain spaces.
The user name can contain alphanumeric characters and any of the following special
characters:
Allowed Special
Character
Description
At sign
Dash
Exclamation point or bang
Period or dot
Underscore
When creating passwords, the following rule applies:
The maximum length of a password is 32 characters.
Creating a New SOX Express User

When creating a new SOX Express user, you must first select the group to which the user will
belong, and then enter information about the user and user account. If you have not created an
appropriate group for the new user, add them to the SOXUsers group.
If the user will be responsible for adding, editing, or removing reports or access control lists
(ACLs), the account should be added to the SOXAdministrators group.
To create a new SOX Express user:
1.
2.
3.
Log into SOX Express with an account that has permissions to add and modify users
and groups.
Click on the Users / Groups link under the Administration heading. The list of SOX
Express users and groups is displayed.
Expand the list of groups and users until the group to which you want to add the new
user is displayed. Click the name of the group to display the Group Details page.
4.
5.
Scroll down to the Users section that lists all of the users who currently belong to the
group. Click the Add New... button.
Enter the necessary information for the new user account. When you are finished, click
Create to continue.
Note: User names must contain only alphanumeric characters and underscores, and
cannot contain spaces. User names and passwords are limited to 32 characters.
Modifying an Existing User Account

To edit a user account:
1.
and groups.
2. Click on the Users and Groups link under the Administration heading. The list of
SOX Express users and groups is displayed.
3. Expand the list until the user account you wish to edit is shown and then click on the
user name to display the Details page.
4. Click the Edit... button at the top of the User Information section. The Edit User
Information page is displayed.
Note: You may not change a users user name.
5.
Edit the necessary information, and click Save to return to the User Details page.
Disabling a User Account

User accounts cannot be deleted in SOX Express. Disabling a user account prevents the user of
that account from logging in.
To disable a user account:
1.
2.
3.
4.
and groups.
Click on the Users and Groups link under the Administration heading. The list of
Expand the list until the user account you wish to disable is shown and then click on the
user name to display the Details page.
Click the Disable button at the top of the User Information section. The button text
changes to Enable and the value of the Active field changes to False.
Re-enabling a SOX Express User

To enable a disabled user account:
1.
2.
3.
4.
and groups.
Expand the list until the disabled user account you wish to enable is shown and then
click on the user name to display the Details page.
Click the Enable button at the top of the User Information section. The button text
changes to Disable and the value of the Active field changes to False.
Associating an Existing User with a Group

To add a new user to a SOX Express group:
1.
and groups.
2. Click on the Users and Groups link under the Administration heading. The list of
3. Navigate to the group to which you want to add a user.
4. Click the group name to display the Details page.
5. Click the Associate... button at the top of the Users table. The Select Users page is
displayed.
6. Expand the user list to find the user you wish to add.
7. Select the checkbox next to the user account you wish to add to the group and click the
Associate button to add the user to the current group.
Disassociating a User from a Group

To disassociate a user from a group:
1.
2.
3.
4.
5.
and groups.
Expand the list of groups and users and click the name of the desired user group.
Scroll down to the Users section of the Details page
Select the checkbox next to the user you wish to remove from the group and click the
Disassociate button to remove the user from the group.
Creating a Group
Users with the correct permissions can create groups using the SOX Express User/Group
interface. Groups can contain other groups and users, and inherit application permissions from
the groups that they belong to.
To create a new group:
1.
2.
3.
4.
5.
and groups.
Expand the list and click on the name of the group to which the new group will belong.
If there is no higher-level group for the new group, click on SOXUsers. The Details
page of the group is displayed.
Scroll down to the Sub-Groups section of the Details page and click Add New...
Fill in the required information for the new group and click Create. The parent groups
Details page is displayed with the new group listed in the Sub-Groups section.
Note: Group names must contain only alphanumeric characters and underscores, and
cannot contain spaces. Group names are limited to 40 characters.
6.
Click the name of the new group to view the Details page if you want to add users to
the group or modify the group permissions.
Tip: Finding Users Quickly

In order to more easily find a specific user without browsing through multiple groups and
subgroups, it is recommended that you create an Everyone group (or other suitable name) as
a sub-group of the SOXUsers group.
This is useful since normally you create SOX Express users in the context of a group, and then
add them to multiple groups directly. This means that in order to find an existing user, you
need to know a group to which the user belongs. To help this process, follow the suggestions
below.
As you create your list of SOX Express users, add them directly to the Everyone group as well
as the functional groups they will belong to. In this manner, to find a specific user quickly, you
can open the Everyone group and select the user directly.
If you want to deny a user access to SOX Express by removing him from all SOX groups, you
will need to remove him from the Everyone group as well.
Note: If you have set up your security access controls for your groups and users, it is
important that the Everyone group is not granted access control to your SOX data. Otherwise,
the access permissions of the Everyone group may override your security settings. The
Everyone group is merely a convenience to help administrators quickly find a specific user
and modify their information.
Removing a Sub-Group
When you remove a sub-group from a SOX Express group and that sub-group does not belong
to any other SOX Express group, the sub-group will not appear in the Users/Groups listing.
When adding an existing group to another group, the removed group will still be available in
the group selector list.
Note: If you remove a sub-group from the SOXUsers group, and the members of that group do
not belong to any other groups that inherit permissions from the SOXUsers group, they will no
longer be able to log in to SOX Express.
To remove a sub-group from a group:
1.
2.
3.
4.
5.
and groups.
Expand the list and click on the name of the group to which the soon-to-be-deleted
group belongs. The Details page of the group is displayed.
Scroll down to the Sub-Groups section of the Details page, select the checkbox next to
the group to be deleted, and click Disassociate. A confirmation dialog is displayed.
Click OK in the dialog to disassociate the selected group(s)
Using Application Permissions 10
Using Application Permissions

Overview of the SOX Express Application Permissions
Sarbanes-Oxley Express (SOX Express) provides a set of application permissions that
administrators can use to limit the activities of the various user groups that can access the SOX
Express application.
This section provides a quick overview of the different SOX Express-specific permissions
available to administrative users.
All of the permissions can be accessed through the Details page of the various user groups and
are grouped under the SOX heading. Selecting the SOX permission checkbox will select all of
the SOX permissions. This is only advisable for administrative level users.
SOX Express Application Permissions

The following permissions can be applied to SOX Express user groups:
Administration
This application permission grants all three permissions in the Administration grouping. If you
wish to create an administrative-level group, they will need this permission group. If a user
group possesses any of these permissions, they will see the Administration heading in the
right-hand Action menu with the appropriate sub-headings.
Access Control Lists

Allows members of the user group to view, edit, and remove the access control listings for
compliance objects through the Access Controls link in the left-hand Action menu. See the
Setting Up Security section for more information on Access Control Lists (ACLs).
Object Reset
Allows members of the user group to reset compliance objects for a new reporting period. For
information on governing reset behavior, see the section, Resetting Compliance Objects on
page 46.
Reporting Periods
Allows members of the user group to create and delete Reporting Periods through the
Reporting Periods link in the left-hand Action menu.
Users and Groups

Allows members of the user group to add, modify, and remove users and groups through the
Users/Groups link in the left-hand Action menu.
Audit Trail
This application permission allows members of the user group to view the Audit Trail
information for compliance objects. With this permission enabled, an Audit Trail button can be
selected at the top of the compliance objects Details page.
Browse Files
Allows groups with this permission to view and navigate the Browse Files heading on the
Action menu.
Folders
This application permission allows members of the user group to create new folders in the
compliance object repository that do not correspond to business entities. This allows users to
create their own folder structure.
Issues
The application permission allows members of the user group to view the list of SOX Issues
through the Issues link in the left-hand Action menu.
Project Management
The application permission allows members of the user group to use the Project Management
capabilities available through the Project Management link in the left-hand Action menu.
View Locks
Users with the View Locks permission can view the existing locks on compliance objects. The
View Locks permission does not grant the right to lock or unlock an object - for that you need
either the Lock permission or the Unlock permission.
Other Permissions
The following application permissions are not contained under the SOX permission heading, but
still have an impact on SOX Express application behavior. Application permissions determine
what functional areas and administrative operations a given user or group is able to perform.
Typically, end users do not require applicaiton permissions.
All Permissions
Grants members of the user group all permissions and access to every functional and
administrative area within SOX Express (Web and server).
Administration
Grants members of the user group access to all administrative functions within SOX Express
(Web and server).
Collaboration
This application permission grants all administrative permissions under the Collaboration
grouping that are related to managing tasks and jobs.
Manage Job Tyes

Allows group members to add and modify job types. Job types are templates that can be used
to create individual jobs.
Start Jobs
Allows group members to start a job.
View All Active Jobs

Allows group members to view a list of jobs and the Details page related to a selected job.
Files
This application permission grants all administrative permissions under the Files grouping that
are related to managing files and folders.
Add Folders
Allows group members to create and add new folders.
Cancel Checkout
Allows group members to cancel the file check out process for associated files that were
checked out by others. When a file check out is canceled, the file is checked back into the
system without applying any changes and no new version of the file is created.
Lock
Allows group members to sign off on any SOX Express compliance object, regardless of signoff
or ACL restrictions.
Unlock
Allows group members to unlock any SOX Express compliance object.
Publishing
Add Folder Assignments
Allows group members to create a new folder assignment. Folder assignments link to an
existing folder in the repository and automatically create a reference in the current channel
folder to any files of a particular file type.
Add Folders
Allows group members to create and add a new channel folder.
Add Pages
Allows group members to create and add publishing-specific files that are used to generate
published web pages. Pages are based on page templates.
Add Templates
Allows group members to create and add page templates that are used to create Web pages.
Assign Files
Allows group members to assign files to specific channel folders.
Browse Channels
Allows group members to browse channels. A channel represent the structure of a published
website.
Create Channels
Allows group members to create a new channel for publishing a website.
Manage Rules
Allows group members to add and modify file rules that specify how file assignments are
published within a given channel folder.
Setting Up Security 13
Setting Up Security
Overview of Implementing ACL Security
Sarbanes-Oxley Express allows administrators to grant or deny read, write, delete, and
associate permissions to groups or specific users. These permissions are set using an Access
Control List, or ACL. An ACL is the list of groups and users who have permissions for the
specified folder. You can explicitly set permissions on folders or inherit permissions from a
parent folder.
This section provides an overview of the procedures involved in setting up security for your
internal controls documentation project, as well as the reasoning behind the required group and
ACL structures.
About Access Controls

Access Controls can be set to control the ability to read, write, delete, and associate the
compliance objects in a folder. Each of these settings can be set individually, allowing fine-level
control over user and group access to the contents of a folder. Any folders that contain the SOX
Express compliance objects (business entities, accounts, risks, etc.) can be administered
through ACLs.
Note: SOX Express access controls can only be set at the folder level. Individual objects within
a folder cannot have ACLs - they automatically assume the ACL of the folder. If you have
permissions for one item in a folder, you have the same permissions for the other compliance
objects in that folder.
Explaining Access Permissions

There are four access permissions that users and groups can be given for a folder structure.
The permissions are Read, Write, Delete, and Associate. The section below quickly explains the
different permissions.
Read - the group or user can view the details of the objects contained in the folder and
the folder itself, but cannot edit them. Note that if Read access is denied to a group or
user, they will not be able to SEE the folder, or any folders under that folder.
Write - the group or user can view the details of the objects within a folder and modify
them, but cannot delete them. Write access to a folder is required for creating new
objects within the folder.
Delete - the group or user can delete objects within the folder.
Associate - the group or user can create associations between compliance objects
The settings for the different permissions are:
Granted - the user or group has full access to the specified action (Read/Write/Delete/
Associate). The user can view, modify, or delete the file or folder, depending on the
permission.
Inherited - the setting is inherited from the nearest parent folder that contains an
explicit setting for the permission. If no parent folder has an explicit permission set, the
root folder of the compliance hierarchy sets the permission.
Denied - the user or group cannot perform the specified action. If Read permissions
are denied, the folder will not be displayed in the hierarchical view or the compliance
object view.
Read permission is required for Write and Associate access, and Write access is required in
order for Delete access to be granted. You can select any combination of permissions, but when
you save the ACL, it will be modified to be a valid combination of permissions.
For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/Granted,

when you click Ok, the displayed permissions will be Granted/Granted/Granted/Granted
because users must have Read permissions in order to have Write, Delete, or Associate
permissions. Therefore, the Read permission is automatically changed to Granted.
In order to set Read to Denied, Write, Delete, and Associate must also be set to Denied.
Using ACLs with Top-Level Folders

When setting up your business entity and other compliance object hierarchy, certain folders are
already created for you by the SOX Express installation. These folders are created with pre-set
ACLs, and should not be modified.
Make sure you do not modify the ACLs for the following folders:
Default
BusinessEntity
ICDocumentation
Accounts
ControlObjectives
Controls
Processes
Risks
Signatures
SubAccounts
SubProcesses
Test Results
Tests
Issue
IssueActionItems
Plan
Milestone
Task
Files and Forms
Preparing For Your Security Implementation

Before you can implement your security settings for your internal controls documentation
project, you should do the following:
Set up at least a sample business entity hierarchy for testing purposes

Have a map on hand of your business entity hierarchy for easy reference.
Note: It can also be helpful to have your user accounts created, although you can implement
ACL security without them.
Example: Representing the Corporate Structure with Business Entities

Widgets, Inc. has a main corporate center that centrally controls all of the corporations
outlying regions. Each region has a central authority that is responsible for overseeing all of the
individual sites located within the region. In addition, each site has a staff responsible for
handling the finances and day-to-day operations of their site.
When setting up their compliance object hierarchy, the administrators realized that although
each site needed to be responsible for documenting their own controls, the set of processes and
risks for each site were identical. Therefore, they decided to create a Library of compliance
objects all linked to a Library business entity. The Library business entity would serve as the
blank template for each sites compliance object hierarchy.
First, the administrators created a business entity (CorporateCenter) for the entire corporation.
Then, they created an entire set of internal controls under the Library sub-entity. Once the
hierarchy was complete, they created a business entity under CorporateCenter for each region,
and sub-entities under each region for each regional site. Once the regional site entities were in
place, the administrators copied over the entire compliance object hierarchy from the Library
entity to each regional site. Now each regional site has its own hierarchy, complete with a
unique entity folder structure.
Note that in our example, only the Library and the Site business entities have non-entity
compliance objects in them. The CorporateCenter and all of the Regional entities are just
containers for the Site business entities.
The Compliance Object Folder Structure

When the SOX Express object hierarchy is viewed using the Access Control menu option in
SOX Express, the folder structure is slightly different than the hierarchy shown in the Overview
screens (Account Overview, Entity Overview, etc.). The folder structure of the object hierarchy
looks like the following:
Business entities are contained in their own folder, while all of the other compliance object
types have their own folder underneath the ICDocumentation folder.
Note: ACLs should never be added to folders that were automatically created during the SOX
Express installation (e.g. ICDocumentation, BusinessEntity, etc.). Always create ACLs using the
SOX Express administrative user interface.
When you add a new business entity called Enterprise, a folder with the name of the business
entity is created underneath the BusinessEntity folder, as below:
When you add a sub-entity named Region to the Enterprise entity, a corresponding folder is
created.
When you add other compliance objects to a business entity hierarchy, the folder structure of
the business entities it belongs to is automatically created under the compliance object type
folder. All compliance objects of that type created for that business entity are placed in the
same folder.
Important Note: When you are setting ACLs, it is important to remember to set ACLs for the
business entity folders under the ICDocumentation folder structure, as well as the
BusinessEntity folder structure. If you do not, when you try to access the compliance objects
you will not be able to browse to the objects. You should never set ACLs on the container
folders (e.g. ICDocumentation, BusinessEntity).
Using Inheritance with Access Control Lists

By default, folders in the SOX Express compliance object folder hierarchy inherit their security
ACLs from the folders above them. If a folder does not have an ACL set for a particular group,
the application looks back up the folder tree until it finds an ACL for that group and uses it for
the current folder. By default, all users can edit any compliance object in the entire project.
This setup is extremely useful for smaller projects, where there is a single (or very few) teams
all working on the same business entity structure. In the odd case where you have specific
users who are denied viewing or editing privileges, you can easily deny them access to a
particular folder structure by setting an explicit ACL for the group or user that denies them
access.
However, this paradigm rapidly becomes unwieldy for large numbers of groups or business
entities. If you only want a group to see one particular region or site out of 50, it is much
simpler to grant access to the single site than to deny access to the other 49.
About Breaking Inheritance

Using the SOX Express user interface, you can break the inheritance property on any folder.
When you break inheritance, access is limited to ONLY the groups and users who have an ACL
for that business entity. All other groups and users (besides the creator of the object) are
automatically set to Denied/Denied/Denied.
For large teams and projects who wish to restrict which areas of the IC documentation project
can be seen or modified, breaking the inheritance chain is very helpful, since it automatically
denies all groups and users access to the particular business entity structure. Only the groups
and users specifically included in an ACL have access to the business entity children.
Instead of denying a group access to 49 sites, as in the example above, now you only have to
grant access to the desired site, and the other 49 are denied by default.
Note: Breaking inheritance is not without its drawbacks. Because all groups (except
SOXAdministrators and OPAdministrators) are denied access to the business entity, groups that
do not have an ACL entry cannot see the business entity or any compliance object underneath
the business entity. This is true even if an ACL entry for a specific group is added to a subentity. Because the group (or user) is denied Read access at the parent business entity, they
cannot browse the tree to view the sub-entity where they have access. The following sections
will explain how to circumvent this restriction using nested groups.
To break the inheritance on a folder:
WARNING: Once you break the inheritance on a folder, the new permissions (or lack thereof)
go into effect immediately. Only members of the SOXAdministrators and OPAdminstrators
groups will be able to access the object, unless a specific ACL for a user or group is created.
1.
2.
3.
4.
5.
6.
Log into SOX Express as a user with Administrative privileges.

Click the Access Control link on the Action Menu and navigate to the business entity
folder where you wish to break inheritance (under the Default directory).
When you have found the desired folder, click the name of the folder to display the
Details page.
Click the Add button and choose the desired group or user from the list.
Choose the desired permissions for the group or user by highlighting the appropriate
entries and click the OK button to add the new ACL to the folder.
Now that a valid ACL exists for the folder, click the Disable Inheritance button under
the Folder heading. The value of the Inherit ACL field is changed to false and the
Disable Inheritance button changes to Enable Inheritance.
7.
Click Access Controls in the breadcrumb trail to return to the Access Controls folder
list.
Remember, no one except the groups (and sub-groups of those groups) listed in the Access
Controls table will be able to see the folder or its contents.
Note: The SOXAdministrators group and the creator of a folder or object is exempt from ACL
restrictions. The creator always has Delete access to files and folders he or she has created,
while the SOXAdministrators group has total access to all files and folders.
Creating a New ACL

You must have the Access Control Lists application permission to view or edit ACL settings.
To set an ACL on a folder:
1.
2.
3.
4.
5.
6.
7.
Log into SOX Express as a user with the Access Control Lists application permission.
Click on the Administration | Access Control link in the Action menu. An expandable
list of folders is displayed.
Navigate to the folder whose access control list you want to modify. Click the folder
name to display the Details page of the folder.
Click the Edit... button at the top of the Access Controls table. The Edit Permissions
page is displayed.
Click Add to add a new access control to the list. A dialog box is displayed.
Choose the desired group or user from the drop-down list.
Select the desired permissions by highlighting the appropriate choices and clicking OK
when finished. The dialog closes, and the new ACL appears in the list area of the folder
Details page.
Read permission is required for Write and Associate access, and Write access is
required in order for Delete access to be granted. You can select any combination of
permissions, but when you save the ACL, it will be modified to be a valid combination of
permissions.
For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/
Granted, when you click Ok, the displayed permissions will be Granted/Granted/
Granted/Granted. Because users must have Read permissions in order to have Delete
permissions, the Read permission is changed to Granted.
Note: If you do not set a specific permission, it will be set to Inherited unless a set
access permission (such as Delete) forces the blank permission to Granted.
For example, if you set a folder ACL for a group to Granted for Read, and leave Write,
Delete, and Associate blank, they will be shown in the UI as Granted/Inherited/
Inherited/Inherited. However, if you set the permissions to Granted for Delete, and left
Read, Write, and Associate blank, the ACL would be displayed as Granted/Granted/
Granted/Inherited, since Delete requires Read and Write permissions.
8.
9.
Repeat steps 5 to 7 for each ACL you want to set.

Once you have finished setting the permissions, click the Access Control link in the
Action menu to return to the Access Control list.
Editing an Existing ACL

To edit an existing ACL:
1.
2.
3.
4.
5.
Log into SOX Express as a user with the Manage ACLs application permission.
Click the Access Control link on the Action Menu to display the list of access controls.
Click the checkbox next to the folder name and click the Edit button to display the list
of existing ACLs.
Click the checkbox next to the existing ACL you wish to modify and click the Edit button
to display the Edit ACL page.
Select the desired permissions by highlighting the appropriate choices and clicking
Save when finished. The dialog closes, and the updated ACL appears in the list area of
the Access Control page.
Read permission is required for Write and Associate access, and Write access is
required in order for Delete access to be granted. You can select any combination of
permissions, but when you save the ACL, it will be modified to be a valid combination of
permissions.
For example, if you set Read/Write/Delete/Associate to Denied/Granted/Granted/
Granted, when you click Ok, the displayed permissions will be Granted/Granted/
Granted/Granted. Because users must have Read permissions in order to have Delete
permissions, the Read permission is changed to Granted.
For example, if you set a folder ACL for a group to Granted for Read, and leave Write
and Delete blank, they will be shown in the UI as Granted/Inherited/Inherited.
However, if you set the permissions to Granted for Delete, and left Read and Write
blank, the ACL would be displayed as Granted/Granted/Granted, since Delete requires
Read and Write permissions.
Deleting an Existing ACL

To delete an existing ACL:
1.
2.
3.
4.
5.
Click the Access Control link on the Action Menu to display the list of access controls.
Navigate the folder tree to display the folder containing the ACL you want to change.
Click the folder name to display the Details page with the list of existing ACLs.
Click the checkbox next to the existing ACL you wish to remove and click the Delete
button to remove the ACL.
Note: If you have broken inheritance for a folder, there will be entries for the
SOXAdministrators and OPAdministrators groups. These ACLs cannot be edited or
deleted.
Using Groups to Establish User Roles

User groups fulfill three functions - to segregate users into meaningful subsets, to define ACLs
to limit both the range of actions that can be performed on a folders contents, and to limit the
scope of a users activity to a specific folder or set of folders. In this section, we will examine
how groups can be used to separate a set of users into different roles within an organization.
The Core SOX Express Groups

SOX Express has two pre-defined user groups already created as part of the initial installation.
These groups are:
SOXUsers - This group is a container for all users who are part of the SOX Express
application. Every SOX Express user will be a part of this group through inheritance.
The SOXUsers group has a single sub-group - SOXAdministrators.
Note: The SOXUsers group should never be used to set ACLs on any folder. The group
exists for administrative purposes only.
SOXAdministrators - In order to have administrative-level permissions, users must

be part of this group. Administrators can customize reports, create users and groups
through the OpenPages user interface, and assign and modify ACLs. They also have
access to all folders and objects in the SOX Express hierarchy, regardless of ACLs.
Example: Using Groups to Establish User Roles

Widgets, Inc. has decided that they will divide their SOX Express users into four main teams,
each responsible for a different area of their internal controls documentation project. These
four teams are:
The Executive Team. These are people who do not document or modify individual
compliance objects. As a team, they are only interested in viewing the entire internal
controls documentation process as a whole, and quantifying the results. CFOs and
high-level corporate users fall into this category. They need read access to almost all
folders in order to run reports on the documentation project as a whole.
The System Team. This group is responsible for setting up and maintaining the entire
hierarchy of SOX Express compliance objects. They are also the only ones allowed to
modify anything above the control level. In most companies, the IT department or a
sub-set of the central accounting team is responsible for these activities.
The Regional Teams. These groups are responsible for developing, maintaining, and
overseeing the compliance objects for all of the sites within their regions.
The Site Teams. These groups are responsible for documenting the controls for their
sites, as well as uploading test results and control documents.
The Executive and System teams are both based in the Corporate Center, while the Regional
Teams and Site Teams are located in their respective regional and site headquarters.
Although you can have user groups that correspond to the entire team, they are not necessary
when setting ACLs. However, so-called team groups can be helpful for organizational
purposes as well as assigning tasks or other uses. The important groups within each team will
divide the teams according to the level of interaction (Reading, Writing, Deleting, Associating)
they will be allowed, as well as the scope of the folders they can act on. These groups will be
explained in the following sections.
Using Groups to Limit User Activities

Groups are used in folder ACLs to limit what each group of users can do to the compliance
objects located in the folder. In general, you will want a group of users who are limited to just
viewing the compliance objects, a group who can both view and edit the objects, and another
group who can view, edit, associate and delete the objects.
In the following sections, we will divide each team into subgroups with different access
privileges.
The Executive Team

The Executive team is interested mainly in the overall status of the internal controls
documentation project, and gathers most of their information by running reports on the various
compliance objects and drilling down into the objects via the report links. As such, they only
need read access to objects, but their scope needs to be extremely wide.
Some possible sub-groups of the Enterprise team are:
FinancialOfficers
ExternalAuditors
InternalAuditors
In the case of the Executive Team, the sub-groups are merely organizational in nature.
However, by making them sub-groups of the Executive Team group, you gain the flexibility of
categorizing the Executive users by roles without adding complexity to your ACL definitions.
All of the sub-groups require the same access to the compliance object hierarchy - they only
need Read access in order to run reports and view individual objects from those reports. As an
organizational grouping, the ExecutiveTeam group will not appear in any ACLs directly - rather,
it will be added as a member of many other groups with read-only access.
Once you have created your Executive Team sub-groups, add the appropriate users to each
sub-group. Users should NOT be added directly to the ExecutiveTeam group - add them to a
sub-group instead.
The System Team

The System team is responsible for creating, maintaining, and expanding the entire hierarchy
of compliance objects and their associations. Of all the teams, they need the widest authority to
make changes to the compliance object structure. However, not everyone on the team needs
the same permissions. Using sub-groups, we can separate the System team into their separate
roles. The sub-groups for the System team are:
SystemReviewers - contains all users responsible for reviewing newly created

compliance objects and reporting errors in setup or descriptions. They require Read
access.
SystemWriters - contains all users responsible for creating and modifying new or
changed compliance objects, and implementing any changes found by the Reviewers.
They require Read, Write, and Associate access to compliance objects.
SystemDirectors - contains all users responsible for making modifications to the
object hierarchy itself, including removing unnecessary compliance objects. They
require Read, Write, Associate, and Delete access.
Since the System team is responsible for modifying the entire object hierarchy, as well as
reports, projects, etc, they also need to be granted access at the highest level in the entity
hierarchy.
Once you have finished creating the SystemTeam sub-groups, add the System users to the
appropriate System user group, depending on their role.
Note: When looking at this group, you might be tempted to add the ExecutiveTeam group to
the SystemReviewer group. After all, they both need Read access to everything - why not? One
small reason - the Library business entity. As the blank template for any new Regions or Sites
that might be created, the SystemReviewers will need access to the Library. The
ExecutiveTeam group, however, does not want access to the Library, since they will not want to
include the Library objects in any reports they run. Dont forget that the scope of what you can
see determines the content of any reports you run. Reports will not include any objects you
cannot view.
Setting up the System team demonstrates the ability to use sub-groups to refine the
permissions and access levels within a specific organization.
The Regional Teams

Each Regional team (one for each region) is responsible for reviewing and maintaining the
compliance objects that are specific to the sites in their region. In function, they are quite
similar to the System team, but their influence is limited to all of the sites in their region.
The various sub-groups for the Regional teams are actually two levels - first you need an
umbrella RegionalTeams group. Under that group, you need to create sub-groups for each
region.
For example:
Region01Reviewers - responsible for reviewing and reporting on all of the sites in

Region 01. They require Read access to everything in Region 01.
Region01Writers - responsible for making any necessary changes to the compliance
objects in any of the sites in Region 01. They require Read, Write, and Associate access
to everything in Region 01.
Region01Directors - responsible for deleting obsolete compliance objects or defunct
sites in Region 01. They require Read, Write, Associate, and Delete access to
everything in Region 01.
You would create a set of groups for each region in your company (Region02Reviewers,
Region02Writers, etc.). Once you have completed creating a set of groups for each region and
added all of the users from the Regional Teams who belong directly to each group, it is time to
create the groups for each Site.
The Site Teams

Below the Regional level, each Site has its own team of Reviewers, Writers, and Directors. For
each site in each region, you would create a set of sub-groups as follows:
R01Site01Reviewers - responsible for reviewing and reporting on Site 01 in Region

01. They require Read access to everything in Site 01.
R01Site01Writers - responsible for making any necessary changes to the compliance
objects in Site 01 in Region 01. They require Read, Write, and Associate access to
everything in Site 01.
R01Site01Directors - responsible for deleting obsolete compliance objects or defunct
sites in Site 01 in Region 01. They require Read, Write, Associate, and Delete access to
everything in Site 01.
Just like at the Regional level, you would create a set of sub-groups for each site in each
Region. Although by this time we are probably creating a lot of groups, each group will only
have to be declared in an ACL once at the site level.
As you create the Site groups, you can add the users who belong directly to each group. Adding
groups to other groups will be handled in the next section.
Using Nested Groups to Limit User Scope

By now, you have created dozens and dozens of groups, and you havent actually created any
ACLs! Not to worry - this is where all of those groups come in handy. In this section, we will
nest our groups inside one another, add ACLs to our regions and sites, and break the
inheritance of our business entities to restrict the scope of our users and groups. Lets take the
last one first.
Step One: Breaking Folder Inheritance

The first step in limiting user access to regions and sites is to break the inheritance of all of our
business entity folders - all regions and all sites. Breaking the inheritance sets all of the groups
and users without an ACL (except those with the Access Control Lists application permission) on
the business entity folder to Denied/Denied/Denied/Denied. They cant view, edit, or delete the
folder, create or remove associations, or view any business entity folder underneath it, even if
they have an ACL set on a lower-level folder.
The Read permission is the most important, for Read allows you to see folders underneath the
business entity and navigate down to them. However, with so many Regions and Sites to set
up, we dont want to have to keep Denying access to all sorts of groups.
To set ACLs and break inheritance in the SOX Express user interface:
1.
2.
3.
4.
5.
6.
7.
8.
Click the Access Control link on the Action Menu and navigate to the business entity
folder where you wish to break inheritance (under the Default directory).
When you have found the desired folder, click the name of the folder to display the
Details page.
Click the Add button in the Access Controls table and choose the desired group or user
from the list.
Choose the desired permissions for the group or user by highlighting the appropriate
entries and click the OK button to add the new ACL to the folder.
Now that a valid ACL exists for the folder, click the Disable Inheritance button under
the Folder heading. The value of the Inherit ACL field is changed to false and the
Disable Inheritance button changes to Enable Inheritance.
Click Access Controls in the breadcrumb trail to return to the Access Controls folder
list.
Repeat this procedure for each business entity folder.
Note: Do not forget to modify the business entity folders under each compliance object
type in the ICDocumentation tree.
Step Two: Nesting Your User Groups

Now you have a lot of groups with users assigned to them according to their role. In this step,
we will add groups to other groups in order to properly restrict their area of effect.
The way groups with users nest seems backwards at first glance - the most general groups (the
System and Executive groups) have to be added to the more limited ones (the Regional
groups), while the Regional groups have to be added to the most limited ones (the Site
groups).
If the Region01Writers group belonged to the SystemWriters group, which can read, write, and
associate to all regions, they would also be able to read and write to all Regions, which is not
the desired behavior. We are trying to limit user scope, not enhance it. So adding smaller
groups to larger groups doesnt work out correctly.
If you add the larger Regional groups to the smaller Site groups beneath them, you dont
increase the smaller groups scope beyond its boundaries, but the Regional groups extend their
vision downwards into all of the sites in their own Region. (Remember, since we broke
inheritance at each level of the business entity, Regional groups dont automatically get to see
the Sites underneath their Region.)
Heres a diagram that shows the way this works:
Lets follow one use case shown in the preceding diagram. The SystemWriters group becomes a
sub-group to the Region01Writers group (and the Region02Writers group, and so on). Then,
the Region01Writers group becomes a sub-group of the R01Site01Writers group (and the
R01Site02Writers group, etc.). The sub-groups of Region01Writers also become sub-groups of
R01Site01Writers through group inheritance. The effective members list of R01Site01Writers is
now:
R01Site01Writers
<writer1>
<writer2>
...
Region01Writers
(SystemWriters)
In the above example, SystemWriters is in parenthesis, because it isnt explicitly added to the
group - its included as a sub-group of the RegionalXXWriters groups. The same goes for the
ExecutiveTeam group; it is added to each of the RegionXXReviewers groups. Executives only
need Read access, so we dont need to add them to any other ACL classification.
Note: If you are using the Library paradigm, you do not want to add the ExecutiveTeam group
to the Library group. You dont want empty Library data included into the executive level
reports.
Now lets explore how we can use our nested groups to set our ACLs.
Step Three: Setting Folder Access Control Lists

Now that we have user groups with different permission needs for each site, we can start
creating our ACLs. For each Site, we create an ACL for each R##Site## group and give them
the necessary permissions. For example, in R01Site01, the ACLs for the business entity folder
would look like this:
We dont need to specify the Region01Reviewers, Writers, or Directors - they are already
included as members of the R01Site01 groups!
In general, you only need to specify ACLs for different access control levels (Read, Write,
Delete, Associate) for business entity folders that contain non-business entity compliance
objects. For example, in our hierarchy, Regions only contain the sub-entity Sites - there are no
accounts, processes, etc. directly associated with a Region. Therefore, we dont have to create
ACLs for Region01Reviewers and the other ACL-specific groups at the Region level. In our
current example, heres the ACL list for Region01:
Heres are some general guidelines for whether or not to create an ACL for a user group on a
business entity:
If the business entity has accounts or processes associated with it, you need to create
an ACL for each entity-specific group (such as R01Site1Writers, etc.) with the correct
privileges.
When you create ACLs for a business entity, you must replicate the ACL for each
business entity folder underneath the ICDocumentation folder structure. For example,
you must create the same ACL list for the ICDocumentation/Accounts/Region01/
R01Site01 folder that you created for the BusinessEntities/Region01/R01Site01 folder,
and so on through each sub-folder structure under ICDocumentation (Accounts,
Processes, Risks, Controls, etc.).
Note: If no folder with the correct name exists, either there is no compliance object of
that type currently in the business entitys hierarchy, or a parent folders ACLs do not
include a group that contains the current user, preventing you from seeing the folder.
If a business entity only has sub-entities associated with it, you should not create
individual ACLs for the business entitys Reviewer, Writer, and Director groups. We will
deal with this in the next section,
Only one step remains - weve created the ACLs for our business entities, but when you log in,
you can only see the first level of your business entities! We now need to establish read
permissions in the business entities above our Site user groups, so that we can browse down to
the Site level and view our compliance objects.
Using Group ACLs to Traverse Business Entities

Even though we have successfully created a nested series of groups that successfully limits the
scope of our site users, we seem to have gone a little too far - we cant browse through the
business entities to get to our site! We need to create a group that will allow site users to
browse through the entities, without granting anything but Read.
To allow Read access to lower-level user groups:
1.
2.
3.
4.
5.
6.
Log into SOX Express as a user with Administrative privileges.

Click the Users / Groups link in the Action menu to display a list of the available
groups and users.
Create a new group at the Region level (actually, at any level above the lowest, if you
have more than two levels). Call the new group Region01Browsers, because thats what
its purpose will be - to allow users from the entities below it to browse down to their
site.
Create a similar group for each business entity above the lowest level (Site, in our
example).
Click the Access Controls link in the Action menu and navigate into your business
entity folder structure (under \Default\BusinessEntities).
Create an ACL on Region01 and grant Region01Browsers Read access. Repeat this with
Region02Browsers in the Region02 business entity folders, and so on in any other
Regions youve created.
In order to not make the Browsers groups unwieldy, well need to roll-up each sites
users into a single group that can be added to the Region01Browsers group.
7.
Add the R01Site01Directors and R01Site01Writers group to the R01Site01Reviewers

group.
8. Add the R01Site01Reviewers group to the Region01Browsers group. This has the effect
of adding all of the R01Site01 groups to the Browsers group, even though you only
added one.
9. Repeat the process for the rest of the business entities.
10. If you have more than one level above your lowest level, you will need to link the
Browsers groups together, creating a chain to the highest level of business entity.
For example, if we had top-level business entities called Country01, etc., we would
create a group called Country01Browsers, and add the Region01Browsers group to it.
However, if Region02 was not a child of Country01, you would not add
Region02Browsers to the Country01Browsers group.
11. Once the groups have been added, log out and log back in with a Site level user and
test that the ACLs are working correctly.
Setting Up LDAP User Authentication 27
Setting Up LDAP User Authentication

Overview of LDAP Authentication
SOX Express supports the use of an LDAP authentication server to control user access. This
section details the configuration steps required to integrate SOX Express with an LDAP data
source.
Only one login module can be active at the same time. The underlying Openpages platform
supports a single namespace, so all users must be authenticated through the same data
source. Multiple authentication modules cannot be used at the same time.
Any users that are created or imported into SOX Express must also be present in the LDAP
authentication server. It is the responsibility of the person managing the SOX Express users to
maintain the correlation between the SOX Express user list and the external LDAP data source.
If a user is disabled on the SOX Express server, they must be manually disabled on the LDAP
Directory server.
Note: If an LDAP Directory Server is being used for user authentication, the Change
Password button will be disabled in the SOX Express user interface. When an LDAP server is
used, passwords are not maintained in SOX Express. The password must be changed directly in
the LDAP server.
Supported LDAP Servers

SOX Express has been certified for use with the following LDAP servers:
Microsoft Active Directory

Sun One Directory Server (formerly known as iPlanet Directory Server)
Configuring the LDAP Authentication Module

To successfully use an LDAP Directory Server with SOX Express, you must configure the LDAP
Authentication Module to recognize the presence of the LDAP server. This is accomplished by
completing the following steps:
Adding the necessary users to the LDAP server

Changing the OPSystem password (optional)
Modifying the LDAP configuration file
The following sections will detail the steps required to configure SOX Express to work with an
external LDAP authentication source.
Step One: Adding Existing Users to the LDAP Server

Please refer to your LDAP Directory Server documentation for the steps required to add SOX
Express users to the LDAP server.
All users that will need access to the SOX Express or OpenPages platforms must be added to
the LDAP authentication server. In addition, the following users will need to be added to the
LDAP server:
OPSystem
OPAdministrator (only if you are using this account)
SOXAdministrator (only if you are using this account)
Note: If you specify a password for the OPSystem account that is different from the one
installed by the product, you will need to complete Step Two to change the OPSystem account
password system-wide.
Step Two: Changing the OPSystem Password (optional)

If the OPSystem password on the LDAP server does not match the one installed by SOX
Express, you will need to change the OPSystem password using the provided tool.
To change the OPSystem password:
1.
2.
Start all services.

Run the following batch file:
<WL_HOME>/aurora/bin/chng-sys-pswd.bat
<WL_HOME> is the home directory for your WebLogic installation. By default, this
location is c:\bea\weblogic81.
You will be prompted for the old OPSystem password and then the new password.
3.
Open and edit the <OP_WORKFLOW>\bin\twf.ini file.

<OP_WORKFLOW> is the Workflow directory of your SOX Express installation. By
default, this location is c:\OP_Workflow.
4.
5.
6.
Find the line that contains the TWFServerPassword property and change the value to
the new OPSystem password.
Save your changes and exit.
Restart all services in order to enable the new password.
Step Three: Editing the LDAP Configuration File

Finally, you must modify the authentication configuration file to enable the LDAP Directory
Server you are using.
The aurora_auth.config file contains three authentication modules:
Openpages - the default internal user directory

OpenpagesIP - the LDAP configuration for the Sun One Directory Server
OpenpagesAD - the LDAP configuration for the Microsoft Active Directory Server
The only module that Openpages pays attention to is the module named Openpages.
Therefore, in this step we will modify the configuration file to change the name of the correct
LDAP authentication server module to Openpages, and then change the settings to reflect the
settings of your LDAP server.
To modify the configuration file:
1.
2.
3.
4.
Stop all OpenPages, SOX, and i-Flow services.

Open and edit the <WL_HOME>\aurora\conf\aurora_auth.config file in a text editor.
Find the module named Openpages and change the name to OpenpagesDefault
(without the quotes).
Depending on the LDAP server you intend to use, modify either the OpenpagesIP or
OpenpagesAD module name to Openpages (again without the quotes).
If you are using a Microsoft Active Directory server, change the OpenpagesAD module.
If you are using a Sun One Directory Server, change the OpenpagesIP module.
5.
Specify the correct values for the following properties in the appropriate module:
provider.url - Change the value to the hostname and port number for the LDAP
authentication server.
base.dn - The top level of the LDAP directory tree structure (Domain Name) on
the LDAP server. If the users to be authenticated are located in multiple
locations within your Active Directory structure, you will need to list all of the
locations explicitly by using the distinguished names of the locations, each
separated by a semi-colon.
For example:
base.dn="DC=LDAPTesting,DC=local;CN=Users,DC=LDAPTesting,DC=local;
OU=Auditors,OU=External Auditors,OU=Staff,DC=LDAPTesting,DC=local"
user.attr.id - the attribute name of the user identifier (for example, uid, cn,
etc.)
Additional custom parameters can be added by preceding them with the prefix
ctx.env. (without the quotes).
For example, when using the Sun One Directory Server:
OpenpagesIP
{
com.openpages.aurora.service.security.namespace.LDAPLoginModule
required debug=false
provider.url="ldap://192.168.0.169:30429"
security.authentication="simple"
base.dn="DC=LDAPTesting,DC=local;OU=People,DC=LDAPTesting,
DC=local"
user.attr.id="uid"
ctx.env.your.param="paramvalue"
;
};
An example when using the Microsoft Active Directory server:
6.
7.
OpenpagesAD
{
com.openpages.aurora.service.security.namespace.LDAPLoginModule
required debug=false
provider.url="ldap://192.168.0.165:389"
security.authentication="simple"
security.search.user.dn="CN=Paul Smith,CN=Users,DC=LDAPTesting,
DC=local"
security.search.user.credentials="openpages"
base.dn="CN=Users,DC=LDAPTesting,DC=local"
user.attr.id="sAMAccountName"
;
};
When you are finished editing the file, save your changes and exit.
Restart all services.
Congratulations! You have configured the SOX Express system to use an external LDAP user
authentication server.
Configuring Password Encryption 30
Configuring Password Encryption

Overview
SOX Express contains the ability to modify the encryption algorithm used to encrypt the SOX
Express user passwords. The tool used to modify the encryption is called the
UpdatePasswordEncryptionAlgorithm tool, hereafter referred to as UPEA.
The UPEA tool supports two algorithms - the default encryption algorithm called OP-CUSTOM,
and the Triple DES (3DES) algorithm.
About the UPEA Command File

The UPEA tool is a command file named UpdatePasswordEncryptionAlgorithm.cmd, located in
the <WL_HOME>\config\OpenpagesDomain directory of your SOX Express installation. The
UPEA tool can be used to:
Change the encryption algorithm from OP-CUSTOM to 3DES

Change the encryption algorithm from 3DES to OP-CUSTOM
Change the 3DES encryption key.
Note: When changing the encryption algorithm to 3DES, all user passwords will be reset to
0p3nP4g3s (first character is a zero), and users will need to change their passwords the next
time they log into the system. When changing the encryption algorithm from 3DES to OPCUSTOM, all passwords are unchanged.
Pre-requisites
The following tasks must be completed before running the UPEA tool.
There must be a properly installed and functioning SOX Express 3.0.4 system on the
machine.
All users must log off the system
A full backup of the OP/SOX database must be completed
All SOX Express services should be shut down except for OPAdminWLS. This ensures
that no users are logged onto the system during the password encryption update.
UPEA Syntax
UpdatePasswordEncryptionAlgorithm -Mode [CA|CK] -AlgorithmName [OP-CUSTOM|3DES]
[-ProviderName SunJCE -ProviderClass com.sun.crypto.provider.SunJCE] -Username
OPAdministrator -Password <OPAdministrator password> [-KeySize <length> ][-Port
<portnumber>] [-?]
Parameters:
Parameter
-Mode
Description
Specifies in which mode the tool should run. Possible modes
are:
CA - Change Algorithm Used to switch the encryption
algorithm from OP-CUSTOM to 3DES or 3DES to OP-CUSTOM
CK - Change Key Used to change the 3DES encryption key.
-AlgorithmName
Specifies which encryption algorithm will be put into use.

Valid values are OP-CUSTOM and 3DES.
-ProviderName
Used when changing algorithms to the 3DES encryption

algorithm only. Has only one valid value: SunJCE.
Parameter
Description
-ProviderClass
Used in conjuction with -ProviderName to specify the class for

the new encryption algorithm. Has only one valid value:
com.sun.crypto.provider.SunJCE.
-Username
Specifies the username to use when modifying the user

passwords. Must be OPAdministrator.
-Password
The password to the OPAdministrator account.
-Port
Optional parameter to be used only if the OpenPages

(OPAdminWLS) port has been changed from the default value
of 7001. If so, the value of -Port should be the new port
number.
-KeySize
Specifies the length of the 3DES encryption key. The smallest

valid length is 112. If an invalid value is given, or no value is
provided, the default is the smallest valid size.
-?
Displays the onscreen help for the UPEA tool.
Changing the Password Encryption Algorithms

Note: Only the OPAdminWLS service should be running when using the UPEA tool.
To change the encryption algorithm from OP-CUSTOM (the default) to 3DES:
1.
2.
Log into the application server as a user with Administrative privileges.

Open a command window and change directories to the <WL_HOME>\config\
OpenpagesDomain directory (where <WL_HOME> is the directory where you installed
the BEA WebLogic server. <WL_HOME> defaults to c:\bea\weblogic81.
3. Type in the following command (on a single line) and execute it:
UpdatePasswordEncryptionAlgorithm -Mode CA -AlgorithmName 3DES -ProviderName
SunJCE -ProviderClass com.sun.crypto.provider.SunJCE -Username OPAdministrator Password <password> [-KeySize <length>]
where <password> is the password for the OPAdministrator account.
Note: If you have changed the default port for OpenPages to a port other than 7001,
add the -Port parameter to the end of the command with the new port number.
4.
5.
6.
7.
The tool will display a message describing the changes it will make and ask for
confirmation. Type Y at the prompt and hit Enter to proceed.
Once the UPEA tool has finished, a success message will be displayed.
Restart all SOX Express services.
You (or the site administrator) must notify all users that their passwords have been
reset to 0p3nP4g3s, and that they will need to change their passwords the next time
they log into the system.
To change the encryption algorithm from 3DES to OP-CUSTOM:

1.
2.

UpdatePasswordEncryptionAlgorithm -Mode CA -AlgorithmName OP-CUSTOM -Username
OPAdministrator -Password <password>
4.
5.
6.
Restart the SOX Express services.
Changing the 3DES Encryption Key

At certain times, you may wish to change the encryption key used by the 3DES encryption
algorithm. To change the encryption key:
Note: Only the OPAdminWLS service should be running when using the UPEA tool.
1.
2.

UpdatePasswordEncryptionAlgorithm -Mode CK -AlgorithmName 3DES -Username
OPAdministrator -Password <password>
4.
5.
6.
Working with Reports 33
Working with Reports

SOX Express contains a set of reports that allow users with the correct permissions to quickly
view and organize information about the current state of your Internal Controls Documentation
project. For example, users can quickly view information grouped by user, by location, or view
all controls that are ineffective or are incompletely documented.
Viewing Reports
Reports are accessed through the Reports link in the left-hand Action menu when you are
logged in to SOX Express. If you do not see the Reports link, your account does not have the
necessary privileges to view reports. If you feel that this is in error, please contact your SOX
Express Administrator for additional information.
To view a report:
1.
After logging in to SOX Express, click on the Reports link in the left-hand Action menu.
A page listing all of the available reports is displayed.
2.
Choose the report you wish to view and click the name of the report. A new window is
displayed.
If the report is scoped, you will be prompted to choose the business entity where you
want the report to run from. The report will use the selected business entity as the
starting point and limit the scope of the report to all compliance objects contained
below the entity.
If the report is not scoped, it will run as soon as you click the name of the report.
3.
4.
When you select a report to view, the report is generated in direct response to your request.
This allows you to see up-to-the-minute status of your IC documentation project.
Supplied Reports
Sarbanes-Oxley Express comes with a selection of pre-defined reports that allow you to quickly
view important information about your project. SOX Express contains the following supplied
reports (in alphabetical order):
Reports that are scoped by default are listed in italics.
Report Name
Description
Accounts by Category
Lists all accounts under the selected business entity grouped

by category.
Ad Hoc Tests
Lists all tests where the testing frequency is set to Ad Hoc.
All Documentation
Lists all of the control documentation contained in the selected

business entity.
All Tests
Lists all tests and their associated controls under the selected
business entity.
Annual Tests
Lists all tests where the testing frequency is set to Annually.
At Risk Action Items
Lists all actions due in the next week that are less than 50%
complete.
Audit Overview
Lists all modified compliance objects during a particular time

period. You must have the Audit Trail application permission to
view this report.
Business Entity Survey
Lists the Internal Controls Assessment surveys completed for

Business Entities (if survey reports are loaded).
Checked Out Files by Date
Lists all associated files that have been checked out from the
repository by their check out date. Dates are sorted in
ascending order from oldest to most recent. You must have the
Cancel Checkout application permission to view this report.
Checked Out Files by File

Name
repository by file name for the specified reporting period. You
must have the Cancel Checkout application permission to view
this report.
Checked Out Files by Full

Path
repository by full path name for the specified reporting period.
You must have the Cancel Checkout application permission to
view this report.
Checked Out Files by User
Lists all the users who have files checked out from the
repository for the specified reporting period. You must have
the Cancel Checkout application permission to view this report.
Control Analysis
Process-centric view of Controls
Control Signoff by Business

Entity
Lists for each business entity the number of controls that are
Unsigned, Signed, and Revoked, along with a summary of the
percent of controls signed off for each entity.
Control Signoff by Process
Lists for each process the number of controls that are

percent of controls signed off for each process.
Controls - Account
Dashboard
Lists the number of controls for each account that are

Effective, Ineffective, or Undetermined. Also denotes
Progress - what percentage of controls for the account are
marked Effective.
Report Name
Description
Controls - Business Entities

Dashboard
Lists the number of controls for each business entity that are
marked Effective.
Controls - Processes
Dashboard
Lists the number of controls for each process that are

marked Effective.
Controls by Location
Lists all controls in the current project, grouped by location.
Controls by Performer
Lists all controls, grouped by the person responsible for the

control.
Daily Change Report
Lists the changes made to all compliance objects within the

last 24 hours. You must have the Audit Trail application
permission to view this report
Disassociated Objects by
Name
Lists all compliance objects with no parent for the specified

reporting period. Disassociated object names are sorted in
ascending order.
Disassociated Objects by
Path
Lists all compliance objects with no parent by full path name

for the specified reporting period. Path names are sorted in
ascending order.
Export Business Entities
Exports the selected business entities (with their associated

compliance objects) to XML format for import into a reporting
database.
High priority new Issues
Lists all current issues with status of New and priority of High.
Incomplete Action Items
Lists all action items that are not 100% complete.
Incomplete Documentation
Lists all project entities that do not have sufficient

documentation under the selected business entity.
Ineffective Controls
Lists all ineffective controls under the selected business entity.
Issues and Action Items
Lists all issues and incomplete action items
Issues by Assignee
Lists all issues grouped by the user to which they are assigned.
Issues by Status
Lists all issues grouped by their current status.
Milestones
Lists all milestones and project tasks for the current project.
Monthly Tests
Lists all tests where the testing frequency is set to Monthly

under the selected business entity.
My Tests - Performer
Lists all tests that are performed by the current user.
My Tests - Reviewer
Lists all tests that are reviewed by the current user.
Overdue Action Items
Lists all action items less than 100% complete and past their
due date.
Process Surveys
Lists the Internal Controls Assessment surveys completed for

processes.
Process Tree
Lists all processes and their risks and controls
Processes Signoffs by
Business Entity
Lists for each process the number of controls that are

percent of controls signed off for each process.
Report Name
Description
Quarterly Tests
Lists all tests where the testing frequency is set to Quarterly

under the selected business entity.
Signoffs - Business Entity

Dashboard
Lists whether the Primary and Executive Owners have signed

off on each business entity.
Signoffs - Processes
Dashboard
Lists whether the Primary and Executive Owners have signed

off on each process.
Test Notifications
Creates action items and sends e-mails to notify users who

have Tests without Test Results. Can be run manually
Top-level Processes
Process-centric view of processes and their account and

business entities.
Undetermined Controls
Creates Action Items and e-mail messages to notify users who

have Controls assigned to them that are not marked as
Effective or Ineffective. Can be run automatically or manually.
Understanding Reports
Reports are generated by combining Report Pages and Report Page Templates that provide
necessary information about the filtering and sorting of the report contents, as well as the
displayed name and description of the report.
Reports are represented in a publishing channel by a page template which lists the parameters
that the source file needs in order to create a report. A Report Page contains a set of values for
the parameters specified in the Report Page Template.
In this manner, a single Report Template can be supplied with multiple sets of values for its
parameters. This allows SOX Express to create multiple reports based on the same layout and
internal logic. Each Report Page represents a report as viewed in the SOX Express application.
These report files are contained inside the OpenPages repository. The OpenPages repository
handles the data storage and access capabilities for the SOX Express application. In order to
create, modify, or delete SOX Express reports, you must have an SOX Express account with
permission to modify publishing channels. If you are not sure whether you have access to this
functionality, please see your SOX Express Administrator for additional information.
Accessing the Report Pages and Page Templates

Once you have successfully logged in to OpenPages, complete the following steps to view the
existing report files:
1.
Click on the Browse channels link under the Publishing heading in the left-hand
Action menu. This displays a list of the available publishing channels.
Note: If you cannot see the Publishing heading, you do not have the correct
permissions. See your SOX Express Administrator.
2.
Click the Reporting folder, then the SOX folder. A list of files and folders is displayed.
Each folder represents a report grouping in the SOX Express user interface. Each
Page file represents a SOX Express report.
Creating a New Instance of a Report

To create a new instance of a report, you must create a new Report Page based on a copy of an
existing Report Page Template. The new Report Page will show up in SOX Express as a new
report.
To create a new report:
1.
2.
Log in to the OpenPages web application as a user with the correct Reporting privileges.
Determine which existing report you want to use as the basis for your new report.
For example, if you want to add a new report that is a slightly tweaked version of the
existing Control Analysis report, you would want to use the report template that the
Control Analysis report is based on.
3.
Click on the Browse channels link in the Action menu and find the report you want to
create a modified version of. The SOX reports are listed in folders under the Reporting/
SOX directory.
4. Click the name of the report to view the Details page of the report.
5. Note the value of the Template field. You will need to make a copy of the referenced
template.
6. Click on the Browse Files link in the Action menu and navigate to the Reports folder.
7. Create a new folder under the Reports folder.
8. Navigate under the Reports/SOX folder structure and find the JSP with the same name
as the Template field you just saw.
9. Click the checkbox next to the JSP name and click the Copy To... button.
10. Choose the directory you created in step 7 and click OK to create a copy of the report
template in the target folder.
11. Click on the Browse channels link in the Action menu.
12. Navigate to the folder under the Reporting/SOX folder where you wish your report page
to be created.
Reports placed in the Reports/SOX folder will be displayed in the SOX Express report
list under the heading General Reports. If you wish to create a new heading for your
custom reports, create a new folder underneath the SOX folder.
For example, to create a new report grouping titled My Custom Reports on the
Reports page in SOX Express, create a folder in OpenPages and name it My Custom
Reports. Any reports you create in that folder will appear under that folder structure
on the Reporting page in SOX Express.
13. Click the Add Page button at the top of the window. The Describe page step is
shown.
14. Enter an informative name and description for the page. Make sure they accurately
describe the contents of the report. Note: You will not be able to change the name of a
report after it is created. You will have to delete the report and create a new one to
name the report something else.
15. Select the page template you will use to create the report. Each page template has a
different set of parameters that the report can sort and filter.
Choose the copied template you just created and click Next.
16. Depending on the page template you chose, you will now have to enter the sorting and
filtering information for the report. Supply the required information for the report and
click Apply. After you have applied the modifications, click Finish to create the new
report.
When you log into SOX Express, your report should be visible on the Report page.
Modifying an Existing Report Template

Important Note: If you wish to modify one of the supplied report templates for your own
purposes, you must copy the source JSP and report template to a new location outside the SOX
folder structure, and then modify the copied template. Otherwise, you will risk losing your
changes when upgrading to a newer version of SOX Express.
Occasionally, you may wish to modify one of the reports you have created. In order to modify
an existing report:
1.
2.
3.
4.
After logging into OpenPages, click on the Publishing heading in the left-hand Action
menu.
Navigate to the report you wish to modify and click on the report name to display the
Details page.
Find the section containing the information you wish to change, and click the Edit...
button above the section. An editable version of the information is displayed.
Change the desired settings. If you are changing the parameter sorting information,
you will need to click Apply before clicking Save.
Note: You cannot modify the name of a report. In order to change the name of a
report, you must delete the mis-named report and create an identical report with the
new name.
5.
The modified information is saved and immediately applied to the report.
Deleting a Report
To delete an existing report:
1.
2.
After logging into OpenPages, click on the Publishing heading in the left-hand Action
menu.
Navigate to the report (page) you wish to delete and click the checkbox next to the
report name.
Note: Do not delete a page template! If a page template is deleted, all reports (pages)
based on that template are deleted as well.
3.
4.
Once the report is selected, click the Delete button at the top of the table. A
confirmation dialog is displayed.
Click OK to delete the report.
Creating Interactive Reports

Overview
SOX Express now allows administrative-level users with the option to create interactive reports
that prompt the user at run-time for parameter values. This section explains how to modify
newly-created and existing reports to prompt the user for needed information.
Creating an Interactive Report

You can either modify an existing report to be interactive, or specify an interactive parameter
during report creation. In either case, follow the procedure below to create an interactive
report.
1.
2.
Log in to OpenPages as a user with the application permissions to create and modify
reports.
Click the Browse channels link in the Action menu and navigate to the page template
for the report you wish to modify.
3.
4.
5.
6.
7.
Click the name of the report template (page template) you wish to modify. The Details
page is displayed.
Click the Edit... button above the list of report parameters. The Edit Parameters applet
is displayed.
Click the name of the parameter that you wish to make interactive. The parameter
information is displayed at the bottom of the page.
Click the checkbox marked Interactive Value and click the Apply button on the righthand side of the page.
Repeat steps 5 and 6 for each parameter you wish to make interactive. When you are
finished, click the Save button at the bottom of the page.
The next time the report is run, the user will be prompted to enter a value for each field marked
as an interactive value.
Note: Reports with an interactive parameter named label are a special case and will not
display a dialog to enter a value for label. The label field is included to support reporting
periods and should not be modified.
Although any parameter type can be made an interactive value, at this time SOX Express only
supports three modes of entering values into the value fields when the report is run. The three
supported types are text entry fields, enumerated drop-downs, and file browsers. Unsupported
types may still be marked as interactive, but the value for the field must be entered manually
via a text string at run-time. A valid value must be entered into the value field for the report to
return the correct set of information.
Running an Interactive Report

To run an interactive report:
1.
2.
3.
Click on the Reports link in the SOX Express Action menu. A list of available reports is
displayed.
Navigate to the report you wish to run and click on the name of the report. If the report
contains interactive parameters, a dialog is displayed.
Enter the required information into the text fields.
Note: Although any parameter type can be made an interactive value, at this time SOX
Express only supports three modes of entering values into the value fields when the
report is run. The three supported types are text entry fields, enumerated drop-downs,
and file browsers. Unsupported types may still be marked as interactive, but the value
for the field must be entered manually via a text string at run-time. A valid value must
be entered into the value field for the report to return the correct set of information.
4.
After all of the required information has been entered, click the Next button to
generate the report based on the supplied information. The report is displayed in a new
window.
Limiting the Report Scope 40
Limiting the Report Scope

About the Report Scoping Wizard
Overview
Sarbanes-Oxley Express (SOX Express) contains a reporting tool called the Report Scoping
Wizard. Once configured, the scoping wizard allows users to easily run existing reports against
a limited set of data (a selected business entity hierarchy) without having to tailor a separate
report for each business entity.
The benefits of using the Report Scoping Wizard are diverse - first, you reduce reporting
response time by reducing the amount of data that needs to be accessed by the report. Second,
you allow a single report to take the place of multiple business-entity specific reports. Before
the scoping wizard, you would have had to create a copy of a report (such as All
Documentation) for each specific business entity if you wanted to limit the report scope to just
that entity hierarchy. Third, you can let your business users select their own scope for their
reports, and not have to read their minds to determine the reports they want.
This guide contains the following sections:
About the Report Scoping Wizard (this section)

Using the Report Scoping Wizard
Usage Example
Note: The following example assumes that the Report Scoping Wizard has been installed and
that the All Documentation report has been configured to use the wizard.
A district manager logs into SOX Express and decides to run the All Documentation report to
find out how the internal controls documentation project is progressing for his district. Clicking
on the All Documentation report, he is presented with a hierarchical list of the available toplevel business entities to which he has access. He navigates the list of entities and selects the
sub-district he is interested in and runs the report. The displayed information is automatically
restricted to the sub-district he chose.

Overview
After you have installed the Report Scoping Wizard files, you must configure the behavior of the
scoping tool. This is accomplished by editing two parameters of the Scope Wizard page, as
detailed in the following section.
Configuring the Scope Wizard

To configure the scoping wizard, you must:
1.
2.
3.
4.
5.
6.
Log in to the OpenPages application as a user with Publishing permissions.

Click the Browse Channels link in the Action menu.
Navigate to the Reporting\SOX Sub Reports\Scope Wizard directory.
Click on the name of the Scope Wizard page to display the Details page.
Click the Edit... button above the Parameters section. An editable list of parameters is
displayed.
The only two parameters which need to be set are the first two parameters. The other
parameters are used by the system and should not be modified.
Setting the Level to run report at Parameter

The first parameter is Level to run report at. The value of this parameter determines at which
level of the business entity hierarchy the report will run.
For example, if your business entity hierarchy is set up as:
Corporate Entity
Eastern Division
East Region 1
East Region 2
Western Division
...
Corporate Entity would be Entity Level 1, Eastern/Western Division would be Entity Level 2, and
the Regions would be Entity Level 3.
In the above example, if you set Level to run report at to be 2, as soon as the user running
the report chooses a Level 2 entity, such as Eastern Divison, the report would run on the
contents of that entity.
Setting the Level to run report at to 3 would trigger a report when the user selects East
Region 1 or any other level 3 business entity.
Note: This parameter is global - all reports run through the Scoping Wizard will share the same
value. Currently, you cannot run different reports at different levels using the Scoping Wizard.
Setting the Run Immediately at Parameter

The other setting for the Report Scope Wizard is the Run immediately at parameter. This
parameter allows users to set a specific top-level business entity which, if selected at report
run-time, will automatically trigger a report.
To extend the example above, if another top-level entity were named Master Library, entering
the matching string Master Library into this parameter would cause the report to be
immediately run when the Master Library were selected.
This setting overrides the Level to run report at parameter for the business entity named in
the string. The name of the business entity must match exactly.
Using the Report Scoping Wizard

Overview
Once the Report Scoping Wizard template is installed, you must decide which reports you wish
to configure to use the scoping template. In general, the scoping template is most useful for
segmenting reports that return a great deal of data, such as the All Documentation report.
It can also be useful to scope (interactively limit) reports where users are only interested in a
portion of the results (those sections that apply only to their own division or direct reports). The
criteria for determining which reports you will scope depends on your business practices, and
will change from installation to installation.
Regardless of the scope applied to a report, the report will still be limited by the access rights of
the user running the reports. Objects within the scope of the report that the user does not have
the proper access rights to will not be included in the report.
Scoping a Report
To create an interactive report that will be scoped when the report is run, you must complete
the following tasks:
(optional) Hide the original report.

Make the report interactive
Create a new report based on the scope wizard
Step One: Hide the Original Report

Note: You only need to hide the original report if you do not wish users to be able to run the
original report against the full dataset.
To hide the original report (the un-scoped version):
1.
2.
3.
4.
5.
Log in to the OpenPages application as a user with the proper Publishing permissions.
Click the Browse Channels link in the Action menu.
Navigate the channel folders and find the report page for the report you wish to hide.
Click the name of the page and note the template on which the report is based.
Move the page and the template it is based on to the Reporting\Hidden Reports channel
folder.
Note: If any other pages use the report template you are moving, you must also move
the other pages based on the template. Page templates and pages must maintain the
same relative locations to one another. If necessary, you can create sub-folders under
the Hidden Reports folder.
Step Two: Edit the Report Template

Once you have moved the report and its template to the Hidden Reports folder (or not), you will
need to edit the report template and make the scope parameter interactive.
To do this:
1.
2.
Find the template for the report you are scoping.

On the Details page, click the Edit... button on the Parameter Information table. This
displays the parameters included in the report template.
3. In the list of parameters, click the Scope parameter. The details of the parameter are
shown.
4. Click the checkbox next to Interactive Value and click the Apply button on the right.
5. Click Save to save your changes.
Step Three: Create the Scoped Report

Once you have edited the report template, you must create a new report based on the Scope
Wizard template. This new report will take the settings of the scope wizard and apply them to
the report template you modified in Step Two.
To create the scoped version of the report:
1.
2.
In the original location of the report you want to scope, click Add Page....
Type in the name of the new report and select the Scope Wizard Template as the report
template. Click Next to continue.
Note: If you have moved the original report to a new location (such as Hidden
Reports), you can name the new report the same name as the original. If you did not
move the original report, you will have to choose a different name.
3.
Click Browse... and select the report (pagespec) you want to scope. Click Apply to
modify the parameter, and Finish to create the new report.
You can now log in to SOX Express and run the new report.
Managing Reporting Periods 43
Managing Reporting Periods

Overview of Reporting Periods
A reporting period is a snapshot of the current state of the repository, usually created when
the documentation phase of a quarter or year is complete and ready for attestation.
Administrators with the Reporting Periods application permission can create, modify, and delete
reporting periods.
Past reporting periods can then be viewed and reported on from any time in the future without
rolling back the changes made to the repository after the reporting period was created.
Once a reporting period is created, the existing IC documentation is carried forward to the
current reporting period and can be modified in a normal fashion without altering the state of
the earlier reporting periods data.
Once created, the contents of a reporting period cannot be altered. Any changes to the
compliance objects or files will only be reflected in the current reporting period.
Creating a New Reporting Period

To create a new reporting period, you must have the Reporting Periods application permission.
1.
2.
3.
Click on the Reporting Periods link in the left-hand Action menu. The Reporting
Periods page is displayed.
Click on the Add button at the top of the page. A new page is displayed.
Enter the necessary information into the correct fields and click Create to create the
new reporting period. You are returned to the Reporting Periods page and the new
reporting period is listed in the table.
After adding a new reporting period, the reporting period will be added to the Reporting Period
selection drop-down at the top of each overview and compliance object page.
Changing the Reporting Period Naming Convention

By default, the naming convention for a new reporting period looks like this:
Q1-2004
The naming convention for reporting periods is set in a configuration file named
SOXCustomMessages.properties, located in the applications/sosa/WEB-INF/classes directory of
your BEA WebLogic installation.
The naming convention is controlled by the value of reporting.period.display.format. For
example:
reporting.period.display.format=Fiscal Year:{1} Quarter:{0}
where {1} is the value selected for the Fiscal Year drop-down and {0} is the value of the
Quarter drop-down when the reporting period is created.
For the default setting (with no value for reporting.period.display.format) the line would look
like this:
Q{0}-{1}
To change the naming convention:
1.
2.
Change directories to the <WLHOME>/applications/sosa/WEB-INF/classes directory

and open the SOXCustomMessages.properties file in a text editor.
Copy and paste the following line from the sample area and remove the comment
marker (the leading #)
#reporting.period.display.format=Fiscal Year:{1} Quarter:{0}
3.
Modify the value of reporting.period.display.format to the desired format and save your
changes. For example, to create the following display period name:
Results for Quarter 3 in the year 2004
the necessary line in SOXCustomMessages.properties would look like:
reporting.period.display.format=Results for Quarter {0} in the year {1}
When the naming convention for reporting periods is modified, all reporting periods will adopt
the new naming scheme.
After changing the value of reporting.period.display.format, the SOX Express services must be
restarted to pick up the changed value.
Deleting a Reporting Period

After you have created a reporting period, occasionally you may have to delete it to reflect latebreaking changes to your financial close, or due to a mistake in the name (e.g. wrong quarter,
wrong year, etc.).
SOX Express supports deletion of reporting periods for a configurable amount of time after the
reporting period is created. Once the deletion period is passed, the reporting period cannot be
deleted in order to prevent the accidental deletion of historical reporting periods.
When a reporting period is deleted, no files are removed from the database. Signoffs and test
results that were suppressed in the current reporting period are restored.
Deleting a Reporting Period

To delete a reporting period:
1.
Click on the Reporting Periods link in the left-hand Action menu. The Reporting
Periods page is displayed.
2. Select the checkbox next to the name of the reporting periods you want to delete.
3. Click on the Delete button at the top of the page. A confirmation dialog is displayed.
4. Click OK to delete the selected reporting period. You are returned to the Reporting
Periods page and the deleted reporting period is removed from the table.
Note: If you cannot delete a reporting period (you click the checkbox and the Delete button
does not activate), the deletion period for that reporting period has expired.
Configuring the Deletion Period

It is possible to configure the amount of time after a reporting period is created in which the
reporting period can be deleted. This property is set in the sosa.properties file (in the
\aurora\conf directory of your SOX Express installation) and defaults to 7 days after the
reporting period is created. The pertinent section of the configuration file looks like this:
#------------------------------------------------------------------# Reporting Periods
#------------------------------------------------------------------# The number of days after which a reporting period can no longer be
# deleted
reporting.period.delete.interval=7
Change the value of reporting.period.delete.interval to modify the number of days after
creation that a reporting period can be deleted.
Changing the deletion period setting will require restarting the SOX Express services.
Accessing Past Reporting Periods

Any SOX Express user can view past reporting periods through the Reporting Period selector at
the top of the overview pages and the compliance object view pages. No user can modify
objects in past reporting periods.
How ACLs and Reporting Periods Interact

When viewing objects, your existing ACLs control which objects you can view in the current
reporting period and in past reporting periods. If your access permissions change in the current
reporting period, you will be able to view the newly accessible items in past reporting periods,
and you will not be able to view items to which you have lost permissions, even if in past
reporting periods you had access to them.
Regardless of your access permissions, you are never allowed to add, edit or remove
compliance objects and/or files from past reporting periods.
How Reporting Periods and Audit Trails Interact

When viewing an audit trail for a compliance object, only the changes made during the
currently selected reporting period are shown. You can view the audit trail for past reporting
periods, but only the change activities for that reporting period will be shown.
You cannot view audit trails for multiple reporting periods on the same page.
Resetting Compliance Objects 46
Resetting Compliance Objects

Overview of Compliance Object Resetting
Compliance Object Resets are a way to automatically modify compliance objects that exist in
the SOX Express repository. Resets can be started by users with the proper permissions from
the Object Reset menu item in the Administration section of the Action menu.
The most common use of the Compliance Object Reset functionality is to reset all of your
compliance objects at the beginning of a new Reporting Period. For example, each quarter you
have controls and tests that need to be reviewed and performed. The results of those tasks are
recorded by updating the properties and attachments of the appropriate compliance objects.
Once all of these quarterly tasks have been completed, and the quarter is finished, you archive
all of the results into a Reporting Period and prepare for the new quarter. However, the existing
compliance objects still display the test results and changed properties of the previous quarter.
Rather than go in and modify the compliance objects by hand, you can use the Compliance
Object Reset capability to take your existing compliance objects and modify their properties
based on the rules in your ruleset.
While Resets work well with the Reporting Period capability of SOX Express, Resets do not
require the existence of a Reporting Period to be utilized.
Note: When modifying properties or using properties within <criteria> tags, you may not use
system properties. System properties are the properties common to all compliance object
types, such as name, description, or creator. Property modifications and ruleset criteria must
use custom properties (non-system properties). If the property you want does not appear in a
property bundle for the appropriate compliance object type, you cannot use it in your ruleset.
Preparing Your Data

Before a Reset is performed, you will need to perform a few tasks to help ensure that the Reset
procedure goes smoothly. It is always recommended that you back up your SOX Express data
before running a Reset. In addition, if you plan on archiving your changes to a Reporting
Period, you will need to set the Reporting Period up before running the Reset.
Backing Up Your SOX Express Data

It is highly recommended that you back up your pre-existing SOX Express data prior to running
a Reset. In this way, an un-modified copy of your data is maintained, in case your Reset ruleset
does not perform as intended.
Creating a Reporting Period (optional)

If you are planning to reset your data as part of the beginning of a new Reporting Period, you
will have to archive the existing data to a Reporting Period. Detailed instructions for creating a
new Reporting Period can be found in Managing Reporting Periods on page 43.
Creating a Ruleset
Compliance Object Resets are rule-based operations on the compliance objects in your SOX
Express repository. The rules that govern how a Reset will affect your data are contained in a
Ruleset. A Ruleset is a set of rules contained in an XML loader file that is created outside of SOX
Express. Multiple Rulesets can be included in a single XML file. The ruleset loader file is loaded
into the system through the Object Manager loader tool. Once the Ruleset is imported, it can be
selected during the Specify Options step of the Compliance Object Reset guided action.
Compliance Object Resets can modify compliance objects in three ways: modifying the value of
a property, deleting a compliance object, and disassociating two compliance objects.
When creating a Ruleset, you must know the bundles, properties, and property values you are
modifying and match them exactly. If you do not specify a valid property or property value, the
property will not be modified.
Note: Before creating a final Ruleset to use for your Reset session, it can be extremely helpful
to create simple Rulesets that contain a single rule from your final Ruleset. Running these
single Rulesets against a known dataset can verify the accuracy of each rule before attempting
a massive modification of your data.
Creating the Ruleset File

To create the ruleset file, open a new text file in a text editor. Save the file with the following
naming convention:
<file-identfier>-op-config.xml
Once the file is saved, you may edit it to create the XML file.
Sample Ruleset
The following is a sample of how a simple Ruleset might look:
<?xml version="1.0" encoding="UTF-8"?>
<openpagesConfiguration xmlFormatVersion="1.20">
<ruleSets>
<ruleSet name="Quarterly Reset"
description="Rule set to be executed at the beginning of each
and every quarter"
type="Object Reset">
<rule name="Rule 1"
description="Property Update rule setting a property"
type="Property Update">
<propertyUpdateRule contentType="SOXControl">
<bundle name="SOXControl">
<property name="Design Effectiveness"
useDefaultValue="false">
<propertyValue name="Not Rated"/>
</property>
</bundle>
</propertyUpdateRule>
</rule>
<rule name="Rule 2"
description="Property Update rule setting a collection of
properties (including a multi-valued one)."
type="Property Update">
<propertyUpdateRule contentType="SOXRisk">
<bundle name="SOXRisk">
<property name="Assertions"
<propertyValue name="Existence"/>
<propertyValue name="Rights and Obligations"/>
</property>
<property name="Impact"
<propertyValue name="Unknown"/>
</property>
</bundle>
</rule>
<rule name="Rule 3"
description="Object Delete rule"
type="Object Delete">
<objectDeleteRule contentType="SOXTestResult"/>
</rule>
<rule name="Rule 4"
description="Object Delete rule with criteria"
type="Object Delete">
<objectDeleteRule contentType="SOXIssue"/>
<criteria logicalOperator="or">
<criterion bundle="SOXIssue"
property="Status"
operator="=">
<propertyValue name="Closed"/>
</criterion>
</criteria>
</rule>
<rule name="Rule 5"
description="Object Disassociate rule"
type="Object Disassociate">
<objectDisassociateRule parentContentType="SOXRisk"
childContentType="SOXDocument"/>
</rule>
</ruleSet>
</ruleSets>
</openpagesConfiguration>
The Ruleset Tag Library

The following XML tags can be used to build a ruleset:
<openpagesConfiguration>
Description: Progenitor tag for the loader file contents. All other tags are contained within the
<openpagesConfiguration> tag.
Parent Tags: None.
Child Tags: <ruleSets>
Syntax:
<openpagesConfiguration xmlFormatVersion="1.15">
</openpagesConfiguration>
Attributes:
Attribute
xmlFormatVersion
Description
Version of the OpenPages XML DTD.
<ruleSets>
Description: Container tag for one or more ruleSet tags.
Parent Tags: <openpagesConfiguration>
Child Tags: <ruleSet>.
Syntax:
<ruleSets>
</ruleSets>
Attributes: None.
<ruleSet>
Description: A ruleset is a collection of rules that will be executed when the ruleset is selected
during a Reset session. Each ruleset is displayed in the SOX Express user interface as a
separate entry in the list of Rulesets.
Parent Tags: <ruleSets>
Child Tags: <rule>
Syntax:
<ruleSet name=Name
description=Description
type=Object Reset
</ruleSet>
Attributes:
Attribute
Description
name
An identifying name for the ruleset. Will be displayed in

the SOX Express user interface.
description
A description of the function of the ruleset.
type
The type of ruleset. Currently, there is only one type Object Reset.
<rule>
Description: Each <rule> tag contains a single rule that will be applied to the SOX Express
data when the ruleset is selected and a Reset session is initiated.
Parent Tags: <ruleSet>
Child Tags: <propertyUpdateRule>, <objectDeleteRule>, <objectDisassociateRule>,
<criteria>
Syntax:
<rule name=Name
description=Description
type=[Property Update|Object Delete|Object Disassociate]
</rule>
Attributes:
Attribute
Description
name
The name of the rule.
description
A description of the function of the rule.
type
The type of rule. There are three types of rules:

Property Update, Object Delete, and Object
Disassociate.
<propertyUpdateRule>
Description: The <propertyUpdateRule> tag defines a rule that modifies the value of an
existing property on a certain object type. Unless modified by the use of the <criteria> tag
within the same <rule> tag, all objects of the specified object type within the scope of the
Reset will be updated.
Parent Tags: <rule>
Child Tags: <bundle>
Syntax:
<propertyUpdateRule contentType=>
Attributes:
Attribute
contentType
Description
Specifies the content type that the rule will be applied
to. Must match a valid SOX Express content type.
<bundle>
Description: The <bundle> tag specifies which bundle contains the property to be modified.
Parent Tags: <propertyUpdateRule>
Child Tags: <property>
Syntax:
<bundle name=
</bundle>
Attributes:
Attribute
Description
name
The name of the property to be modified.
<property>
Description: The <property> tag is used inside a <bundle> tag to specify the property that
will be updated.
Parent Tags: <bundle>
Child Tags: <propertyValue>
Syntax:
<property name=>
useDefaultValue=[true|false]
[<propertyValue>
<propertyValue>]
</property>
Attributes:
Attribute
Description
name
The name of the property to be updated
useDefaultValue
Specifies whether the property should be updated to

reflect the default value of the property (if one exists).
If no default value exists, the property is not updated.
<objectDeleteRule>
Description: The <objectDeleteRule> tag is used to specify an object type for deletion. Unless
modified by the use of the <criteria> tag within the same <rule> tag, all objects of the
specified object type within the scope of the Reset will be deleted.
Parent Tags: <rule>
Child Tags: None.
Syntax:
<objectDeleteRule contentType=/>
Attributes:
Attribute
contentType
Description
Specifies the object type to be deleted. All objects of
this type within the scope of the Reset are deleted.
<objectDisassociateRule>
Description: The <objectDisassociateRule> tag is used to disassociate a compliance object
type from another compliance object type. If you use the <criteria> tag with this rule type, the
criteria must be based on the childs property values. You cannot base a rule on properties or
property values belonging to the parent content type.
Parent Tags: <rule>
Child Tags: None.
Syntax:
<objectDisassociateRule parentContentType=
childContentType=/>
Attributes:
Attribute
Description
parentContentType
Identifies the parent content type that the child

content type is associated with.
childContentType
Identifies the child content type to be disassociated.

Any objects of the child content type associated with
objects of the parent content type within the scope of
the Reset will be disassociated from the parent object.
<criteria>
Description: The <criteria> tag is used to refine the behavior of a rule by specifying the
standards that need to be met in order to invoke the rule. The criteria tag can contain one or
more <criterion> tags that will be judged when deciding whether to apply the rule to a specific
compliance object. It should be noted that criteria can only be applied in a positive manner that is, if the criteria are met, the rule will be used. You cannot specify a rule where if the
criteria are met, the rule is NOT applied.
Parent Tags: <rule>
Child Tags: <criterion>
Syntax:
<criteria logicalOperator=[and|or]>
Attributes:
Attribute
Description
logicalOperator
Specifies whether all of the criterion (and) will be

used to determine whether the rule will be applied to
the object, or if only one of the criterion (or) needs to
be satisfied.
<criterion>
Note: It is strongly recommended that you use a maximum of three criterion within a single
<criteria> tag. Adding additional criterion will increase the processing time required to
complete the Reset.
Description: The <criterion> tag allows the user to specify a property and value(s) that must
match the evaluation specifications set in the <criterion> tag.
Parent Tags: <criteria>
Child Tags: <propertyValue>
Syntax:
<criterion bundle=
property=
operator=[=|<>|<=|<|>|>=|like]
<propertyValue=/>
[<propertyValue=/>]
</criterion>
Attributes:
Attribute
Description
bundle
The property bundle containing the property to be

evaluated.
property
The property name of the property to be evaluated
Attribute
operator
Description
Specifies the manner in which the value of the property
will be evaluated. Valid operators are equal (=), not
equal (<>), greater than (>), less than (<), greater or
equal to (>=), less than or equal to (<=), and like.
Only the equal, not equal, and like operators can be
used with string variables.
Note: The like parameter allows the use of wildcards
in the <propertyValue> tag. These wildcards consist of
the % and _ symbols, which are passed to a SQL
database query against the Oracle database. The
percent mark (%) symbol is used to represent any
number of characters in a location, while the
underscore (_) character is used to represent any
single character in a location.
The usage is consistent with the use of wildcards in a
SQL where clause. See your SQL documentation for
additional information, if needed.
<propertyValue>
Description: The <propertyValue> tag performs two functions, depending on its location. If
the <propertyValue> tag is contained inside a <property> tag, it specifies the new value (or
values) for the updated property. If the <propertyValue> is contained inside a <criterion> tag,
it specifies the relevant property to be considered when applying the criteria.
If you are modifying a enumerated string (drop-down) property that is multi-selectable, you
can place multiple <propertyValue> tags inside the <property> tag. When the rule is
processed, all of the <propertyValue> tags will be evaluated, and the property will be modified
to select all of them.
Parent Tags: <property>, <criterion>
Child Tags: None.
Syntax:
<propertyValue name=/>
Attributes:
Attribute
name
Description
Specifies the value of the property. See the description
of the <propertyValue> tag for details.
Loading the Ruleset

After you have finished creating the ruleset loader file, you will need to use the Object Manager
tool to load the ruleset into the SOX Express system.
To load the ruleset:
1.
2.
Log into the server machine and navigate to the following directory.
<bea-home>\config\OpenpagesDomain
Run the following command on a single line:
ObjectManager load config OPAdministrator <password> <path-to-rulesetxml-file> <file-identfier>
where
<password> is the password to the OPAdminstrator user account.
<path-to-ruleset-XML-file> is the full path to the ruleset file you created.
<file-identifier> is the portion of the ruleset file name preceding -op-config.xml. For
example, if you created a ruleset file called ruleset-op-config.xml, the <fileidentifier> in the ObjectManager command would be ruleset.
3.
The ruleset is now loaded. If you have created multiple ruleset files, repeat this
procedure for each of them.
Updating a Ruleset
If you load a ruleset with the same name as an already-loaded ruleset, the ruleset will be
overwritten with the new rules. To return to an earlier version of the ruleset, you would have to
re-load the original ruleset loader file. Rulesets are not version-controlled.
Performing the Compliance Object Reset

After you have loaded the ruleset you will be using for the Compliance Object Reset, you must
log into the system and begin the Reset.
Preparing for the Reset

The Reset must be run in single user mode - the user performing the Reset should be the only
user logged into the SOX Express system during the Reset. It is suggested that you advise your
users that the system will be down for the duration of the Reset, and that you shut down and
restart the system before beginning the Reset to make certain that you are the only user on the
system.
Note: In order to ensure the system remains unused while the Reset is in progress, you may
wish to change the port number of the SOX Express system when you restart it. Users
accessing the original port will not be able to access the SOX Express system.
The user running the Reset must have the Object Reset application permission. If the user does
not have the Object Reset permission, they will not be able to see the Object Reset menu item
under the Administration heading.
Configuring the Ruleset Parameters

Before executing the Reset, there are some configuration parameters that should be set. In
general, these settings will only need to be set once before your first time initiating a Reset, but
you may wish to change them for different entity trees or ruleset behavior.
The following parameters can be set in the sosa.properties file. This file can be found in the
<bea-home>\config\OpenpagesDomain\applications\sosa\conf directory.
Logging Level
This parameter controls how much information is displayed in the user interface. The line in
sosa.properties is scor.option.logging.level. The possible values are:
Low - display error messages only

Medium - display any error messages and any warning messages.
High - display any errors, warnings, and any informational or diagnostic messages.
No matter which option is chosen, the same amount of information is logged during the Reset
session. The Logging Level setting only controls how much of the logged information is
displayed on the Log page.
The default value for the scor.option.logging.level parameter is High.
Obey ACL Restrictions

This parameter controls whether the Reset occurs against all compliance objects contained
within the scope of the Reset session, or whether the Reset occurs against only those objects
that the user who initiated the Reset has access to. The parameter in sosa.properties is called
scor.option.acl.check. It can have a value of true or false (without quotes).
The default value of the scor.option.acl.check parameter is false.
Obey Locking Restrictions

This parameter controls whether existing locks on compliance objects are honored when
running the Reset. The parameter in sosa.properties is called scor.option.ignore.locks. A value
of true means that locks will be ignored when running the Reset, and a value of false means
that locked objects will not be modified by the Reset.
The default value for the scor.option.ignore.locks parameter is false.
Using the Compliance Object Reset Page

The Compliance Object Reset page contains a table that shows all of the previous Reset
sessions that have been started. The table contains columns with the following information:
the
the
the
the
the
name of the Reset session

description of the Reset session
date and time the Reset began
date and time the Reset completed
current status of the Reset
The table also has an Add New button that can be selected to start a new Reset session. For
more information on starting a new Reset session, see Starting the Compliance Object Reset
on page 57.
Starting the Compliance Object Reset

To begin the Compliance Object Reset, complete the steps in the following procedure.
1.
Log into the SOX Express system as a user with the Object Reset application
permission.
Note: If you have chosen to obey ACL restrictions, the user must have the permissions
to modify the objects within the scope of the Reset. If the user does not have sufficient
permissions, warning messages will be generated in the log, and the compliance
objects will not be modified.
2.
Click the Object Reset link under the Administration heading in the Action menu.
The Compliance Object Reset page is displayed.
3. Click the Add button at the top of the table to create a new Reset. The Specify Options
page is displayed.
4. Enter a name and description for the new Reset.
5. Select a Ruleset from the dropdown list of available Rulesets. The chosen Ruleset will
be used for the new Reset.
6. Click Next to display the Reset Scope page.
7. Choose the Business Entities to which the Reset will be applied by selecting the
checkboxes next to the entity names. Once you have selected the Business Entities,
click the Start Reset button to begin the Reset.
8. A confirmation warning dialog is displayed. If, after reading the warning, you wish to
begin the Reset, click Ok. The Reset begins, and the Compliance Object Reset page is
displayed.
Viewing the Reset Status

The new Reset session is added to the list of Reset sessions on the Compliance Object Reset
page. You can track the progress of the Reset by monitoring the Status column of the table.
The possible values for the Status field are Initiated, In Progress, Completed, or Failed.
The Failed status will only be shown if the system is set to stop the Reset if errors are
encountered. If the system is set to continue on errors, then when the Reset is completed, the
Completed status will be shown. Any errors that occurred during the Reset will be captured in
the Reset Session Log.
Viewing the Reset Session Details

Every time you start a Reset, an entry is added to the Reset Session table. By clicking on the
name of the reset, the Reset Session Details page is displayed for that Reset Session.
The Details page contains the following information:
Name - The name of the Reset Session.
Description - The description of the Reset Session (set during the creation procedure)
Ruleset Name - The name of the Ruleset that was applied during this session.
Created - The time and date the Reset Session was created.
Start Date - The time and date the Reset was begun.
End Date - The time and date the Reset was completed.
Status - The current status of the Reset. The Status can be one of the following values:
Initiated - The Reset has been initialized, and is preparing to modify your data.
In Progress - The Reset is currently modifying the selected data.
Completed - The Reset finished successfully. Depending on whether the Reset was set
to continue on errors, some errors may be reported in the Session Log.
Failed - The Reset did not finish, because errors were encountered. Check the Session
Log for details on what errors occurred.
Created By - The user that initiated the Reset Session.

Scope - The Business Entities that were modified by the Reset.
Logging Level - The level of detail that will be displayed in the Session Log. Can be one of the
following values:
Low - display error messages only

Medium - display any error messages and any warning messages.
High - display any errors, warnings, and any informational or diagnostic messages.
Continue on Error - Whether the Reset Session will log errors and continue to run, or whether
the error will be logged and the session will halt. Value will either be true or false.
Check ACLs - Whether the Reset occurs against all compliance objects contained within the
scope of the Reset session, or whether the Reset occurs against only those objects that the
user who initiated the Reset has access to. It can have a value of true or false.
Ignore Locks - Whether existing locks on compliance objects are honored when running the
Reset. A value of true means that locks were ignored when running the Reset, and a value of
false means that locked objects were modified by the Reset.
Viewing the Reset Session Log

In addition to the Details page, a detailed view of the Reset Session is recorded in the Reset
Session Log. The level of detail depends on the configuration setting. For details on setting the
logging level, see the section Configuring the Ruleset Parameters on page 55
To view the Reset Session Log, click on the View Log button on the Reset Session Details
page.
The Reset Session Log contains three sections - the Error Messages section, the Warning
Messages section, and the Informational Messages section.
Error Messages
The Error Messages section contains the details of any errors encountered by the Reset.
Warning Messages
The Warning Messages section contains any warning messages generated by the Reset.
Informational Messages
The Informational Messages section captures the running details of the Reset - the number of
successful operations, details on the preparation steps that occur during the Initializing phase,
and a summary of the number of errors encountered during the Reset.
After the Reset

After you have performed an Object Reset, it is highly recommended that you refresh the
Reporting database so that users who run third-party reports will immediately see the changes.
If your users are not using a third-party reporting tool, such as Crystal Reports or
CommandCenter, you do not need to perform a reporting schema refresh. The native SOX
Express reports will automatically see the changes.
For detailed information on performing a reporting database refresh, see Enabling Optional
Reporting Tools on page 77.
Starting Jobs from SOX Express Objects

Overview of SOX Express Jobs
SOX Express allows users with the correct permissions to start jobs that are associated with
SOX Express compliance objects. This section will explain how to start a job from a SOX
Express compliance object and how to monitor the current progress of the job.
For a complete explanation of jobs and job types, see the Working with Jobs and Job Types
chapter of the OpenPages User Manual.
For an explanation of enabling job types for a specific type of compliance object, see the
Enabling A Job Type section of the Openpages User Manual.
For instructions on configuring your jobs and administering some of the advanced features of
the SOX Express workflow capabilities, see the Configuring SOX Express chapter of the SOX
Express Administrators Manual.
Starting a Job from a SOX Express Compliance Object

In order to start a job from a compliance object, that job type must have been enabled through
the OpenPages user interface. If you have not enabled the job type, you will not be able to
select the job correctly.
For an explanation of enabling job types for a specific type of compliance object, see the
Enabling A Job Type section of the Openpages User Manual.
To start a job from within a compliance object:
1.
2.
3.
4.
5.
From the Home page, click on the appropriate link in the Action menu for the
compliance object type (Account, Process, etc.) where you are starting a job.
Navigate to the compliance object(s) for which you want to start a job.
Click the checkbox next to the desired compliance object. If you select multiple
compliance objects, a job will be started for each object.
Click the Submit button. The Submit for Approval page is displayed. If the Submit
button is not available, no jobs have been enabled for this type of compliance object.
Fill in the description and a due date (if any) for the job and click Submit to start the
job.
Monitoring Job Progess

You can keep track of what activity has occurred for a job through the My Jobs table on your
Home page. Each job is shown with its name, description, the compliance object it is attached
to, and the currently active task.
Clicking on the name of a currently running job displays the Details page for that job. In the
details page, you can view information about the job, including any comments input by various
users and assignees.
Configuring
SOX Express
This chapter provides information about administering the SOX Express
application, including adding and removing SOX Express users, report
administration, and adding custom fields to SOX Express compliance
objects.
This chapter contains the following topics:
Using The Backup Utility on page 61

Using the Restore Utility on page 63
Generating Object Names on page 64
Managing Signatures and Locks on page 67
Enabling Workflows for SOX Express Objects on page 71
Configuring Job Behavior on page 73
Enabling Optional Reporting Tools on page 77
Changing the Database Passwords on page 85
Using The Backup Utility 61
Using The Backup Utility

Overview of the Backup Utility
The Backup Utility is a tool that allows the user to backup necessary SOX Express and
OpenPages files and databases. As part of the backup process, the following SOX Express and
OpenPages resources are backed up.
SOX Express database and Workflow database

SOX Express storage folder and its content
the aurora.properties and twf.ini files
the config.xml, config.xml.keep, and config.xml.op4 files
all JSP, XML, TLD, and property files under
<WL_HOME>\config\<OpenpagesDomain>\applications\sosa.
Prerequisites
The following software is required to use the Backup/Restore Utility:
SOX Express 3.0.0 or later installed

Oracle Admin Client Software (version 9.2.0.4) installed on the SOX Express Application
Server machine.
Configuring the Backup/Restore Utility

The Backup/Restore Utility is automatically installed during the SOX Express 3.0 installation
procedure.
Using the Backup Utility

To back up your data with the Backup Utility:
1.
2.
Change directory to <WL_HOME>\aurora\bin directory

Execute the following command:
OPBackup <drive>:\<path-to-backup-location>
where drive is the drive where the backup files will be placed, and <path-to-backuplocation> is the name of the folder where the backed up files and database dump files
will be placed.
The <backup-directory-name> is an optional parameter. When <backup-directory-name> is

not specified, the Backup utility will use the default backup location specified in the
<WL_HOME>/aurora/bin/op-backup-recovery.env (BACKUP_LOCATION) file.
Generated Files
Backup Log File
The backup process creates a log file, which is identified by a unique name in the <backupdirectory-name> folder. Each time you run the OPBackup command a separate log file is
generated.
Using The Backup Utility 62
Backed-Up Content
The backup process creates a zip file in the <backup-directory-name>directory. This zip file
contains the necessary backed up data files including the database dump file. This file may be
used as a parameter to the OPRestore command to restore the installation-specific SOX files
and the database. Each time the OPBackup command is run, a separate zip file is created and
each data file is identified by a unique name.
Usage Notes
The OPBackup command uses the Oracle exp command to export the database.
The OPBackup command stops all OpenPages and SOX Express services before
performing any backup operation. It restarts the services when the backup activities
are complete.
Using the Restore Utility 63
Using the Restore Utility

Overview of the Restore Utility
The Restore Utility is used to restore necessary OpenPages and SOX Express files and database
content. The Restore Utility uses a backup file created using the SOX Express Backup Utility.
As part of the restoration process, the following SOX resources gets restored.
OpenPages database and Workflow database

OpenPages storage folder and its content
the aurora.properties and twf.ini files
the config.xml, config.xml.keep, and config.xml.op4 files
Under the <WL_HOME>\config\<OpenpagesDomain>\applications\sosa folder, the following

files get restored.
sosa.properties
webapp.proerties
configTileDefintions.xml
SOXCustomMessages.properties
Using the Restore Utility

To restore backed up data using the Restore Utility
1.
2.
Change directory to <WL_HOME>\aurora\bin directory

Execute the following command
OPRestore <backup-file-name> <path-to-backup-location>
Where
<backup-file-name> is the name of the backup file (without the .zip file
extension)
<path-to-backup-location> is the full path of the folder where the backup file is
located
The restore process creates a log file identified by a unique name in the <backupdirectory-name> folder. Each time you run the OPRestore command, a separate log
file is created.
The OPRestore command uses the Oracle imp command to import the database.
Generating Object Names 64
Generating Object Names

Overview of Name Generation
SOX Express provides the ability to auto-generate the names of newly created compliance
objects. This ability allows users to enforce internal naming policies and ensure unique object
names.
The auto-generation of object names is controlled by a series of settings in the sosa.properties
file. This file must be modified in order to set the autonaming properties. It is possible to turn
autonaming on or off for each compliance object type individually. For example, you may want
all business entities and processes named by hand, but all risks, controls, and test plans named
automatically by SOX Express. This can be accomplished by modifying the appropriate settings
(detailed in Modifying the Naming Settings on page 62).
Modifying the Naming Settings

The sosa.properties file contains a set of four parameters for each compliance object type.
The relevant settings are:
Setting Name
Description
autonaming.sox.<objecttype>.autonamed
Determines whether the object type name

will be autogenerated. Can be set to true
or false.
autonaming.sox.<objecttype>.editable
Determines whether the generated name

can be edited during the creation process.
Can be set to true or false
autonaming.sox.<objecttype>.format
Determines the format of the generated

name. Additional details can be found in
Configuring the Object Name on page 65
autonaming.sox.<objecttype>.parent.default
If the created compliance object has no

parent, the value for this parameter will be
used to replace the %P; variable in the
generated name.
For example, the settings for the Business Entity compliance object type could look like this:
autonaming.sox.SOXBusEntity.autonamed = false
autonaming.sox.SOXBusEntity.editable = false
autonaming.sox.SOXBusEntity.format = %P;_BUSE_%N3;
autonaming.sox.SOXBusEntity.parent.default = ORPHANED
In the above example, Business Entities would not be autonamed. If we change the value of
autonaming.sox.SOXBusEntity.autonamed to true, as below:
autonaming.sox.SOXBusEntity.autonamed = true
autonaming.sox.SOXBusEntity.editable = false
autonaming.sox.SOXBusEntity.format = %P;_BUSE_%N3;
autonaming.sox.SOXBusEntity.parent.default = ORPHANED
New Business Entities would be created with automatically generated names. These names
would not be able to be edited during the creation process (or afterwards).
Configuring the Object Name

The autonaming.sox.<objecttype>.format setting allows you to incorporate some contextual
information about the object, as well as include a incremental number.
There are three variables that you can include in the format of the autogenerated name. They
are %P;, %U;, and %Nn. They are explained in the following table.
Variable
Meaning
%P;
Will be replaced with the name of the parent of the new

object. If the created object has no parent, the value of
autonaming.sox.<objectname>.default will be used.
%U;
Will be replaced with the creators username.
%Nn;
A unique number. The value of n specifies the amount

of padding the number has. For example, the variable
%N5 would result in numbers like 00001, 00002, etc.
%N3 would result in 001, 002, 003 and so on.
In addition to the variables, you can include any valid text as well in the autoname. The name
of a compliance object must be 252 characters or less and cannot contain any of the following
characters:
'/',':','*','\', '"', '<','>','!', '#', '%', '?', '|'
(slash, colon, asterisk, backslash, double quote, less than, greater than, exclamation point
(bang), pound, percentile, question mark, pipe)
Autogenerating Long Names

Be wary of nesting compliance objects with autogenerated names too deep, as the generated
names can stack with repeated use of the %P; variable.
For example, if you autogenerate the names of Processes, Control Objectives, Risks, Controls,
and Tests using the %P; variable for all of them, the following will happen.
The Process Name will be Entity_Name - Process 001 (given the format string %P; - Process
&N3;)
Using the same format through the rest of the compliance object hierarchy, the name of the
associated Control Objectives would be Entity_Name - Process 001 - Control Objective 001
(the parent name plus the rest of the format string).
The Risk name would then be Entity_Name - Process 001 - Control Objective 001 - Risk 001.
The Control name would then be Entity_Name - Process 001 - Control Objective 001 - Risk 001
- Control 001.
And finally, the Test name would be Entity_Name - Process 001 - Control Objective 001 - Risk
001 - Control 001 - Test 001. (85 characters)
With repeated use of the %P; variable, the names can get extremely long. With longer naming
conventions, you could exceed the maximum length of a compliance object name (252
characters).
Naming Examples
Here are some examples of the various ways the variables can be used:
If we use a parent Process of Hiring Practices and a creator of JSmith, and the following
settings in sosa.properties:
autonaming.sox.SOXRisk.autonamed = true
autonaming.sox.SOXRisk.editable = false
autonaming.sox.SOXRisk.format = %P;_RIS_%N7;
autonaming.sox.SOXRisk.parent.default = ORPHANED
The autogenerated name would be Hiring Practices_RIS_0000001
Example 1:
For the autonaming format parameter
autonaming.sox.SOXRisk.format = %P;-Risk-%N5;
the generated Risk name would be Hiring Practices-Risk-00001.
Example 2:
Given a different autonaming format parameter, such as
autonaming.sox.SOXRisk.format = Risk %N3; for %P; (%U;)
would result in the generated name Risk 001 for Hiring Practices (JSmith)
Example 3:
Not all of the variables need to be used in an autogenerated name. For example,
autonaming.sox.SOXRisk.format = Risk %N4;
results in Risk 0001
Example 4:
If the risk HAD no parent process, the value of autonaming.sox.SOXRisk.parent.default would
be used. In this case, the value
autonaming.sox.SOXRisk.format = %P;_RIS_%N7;
results in ORPHANED_RIS_0000001
Managing Signatures and Locks 67
Managing Signatures and Locks

Overview of Signatures and Locks
SOX Express allows users to create signatures on compliance objects. By itself, a signature is
a merely a virtual note that signifies the users agreement that the object meets with their
approval. It has no enforcement powers, and does not prevent the item from being modified
after approval has been given.
There are two ways in which signatures can be applied to a compliance object: manually
through the Add button, or automatically through a workflow task. Your SOX Express system
must be configured to support either method, and they are not exclusive - you can implement
both ways, if desired.
A workflow signature is a signature that is created on an object as a direct result of a workflow
being completed. If all other methods of creating a signature are disabled, the presence of a
signature verifies that the necessary workflow was completed (and when). A manual signature
is added through the compliance objects Details page.
A signature lock is a lock placed on an compliance object and its descendants that prevents the
objects from being modified. The lock is activated by placing a signature on a compliance
object; whether manually or automatically makes no difference. Once the signature is placed,
the lock becomes active. The signed compliance object and all of its associated child compliance
objects below it in the object hierarchy cannot be modified until the signature is revoked or an
administrator removes the lock.
Only one active lock can be placed on a compliance object. Multiple locks can be inherited from
parent compliance objects as those objects are locked.
The following sections will explain how to implement signatures and locking behavior.
Enabling and Disabling Signatures

This section describes how to enable and disable signatures through the sosa.properties file.
Manual Signatures
Manual signatures are added on the Details page of a compliance object. The Signatures table
has an Add button and a Revoke button at the top of the table. Users without the ability to add
signatures to a compliance object will not see the buttons.
In order to add a signature to an object, the user must have write permissions to the object.
Enabling Manual Signatures

When you enable the ability to manually add a signature to a compliance object, you are
actually granting the ability to add a signature to a type of compliance object (i.e. accounts,
business entities, etc.) to a specific group. The group will be able to add a signature to any
object of the proper type that they have read access to.
To enable a user or group to add a signature directly to a compliance object:
1.
Open the sosa.properties file (located in the

\config\OpenpagesDomain\applications\sosa\conf directory under your BEA WebLogic
installation.
2.
3.
Find the line that corresponds to the compliance object type you want to enable
signatures for. The lines for the different types are:
sosa.signature.permission.add.businessentity=
sosa.signature.permission.add.account=
sosa.signature.permission.add.process=
sosa.signature.permission.add.controlobjective=
sosa.signature.permission.add.risk=
sosa.signature.permission.add.control=
sosa.signature.permission.add.test=
Add the name of the group you want to be able to add a signature to the end of the
line. Multiple groups are separated by commas. There cannot be a space after the
comma.
For example, to add the groups Auditors and Managers to the signoff list for processes,
the modified line would look like:
sosa.signature.permission.add.process=Auditors,Managers
Members of the two groups would then be able to add signatures to processes and
subprocesses.
4.
5.
6.
Repeat the process for each group and compliance object type you want to set up.
Save the changes to sosa.properties and exit the text editor.
Restart the SOX Express server to activate the new settings.
Disabling Manual Signatures

To disable manual signatures for a group or a compliance object type:
1.
2.
3.

installation.
Find the line that corresponds to the compliance object type you want to disable
sosa.signature.permission.add.businessentity=
sosa.signature.permission.add.account=
sosa.signature.permission.add.process=
sosa.signature.permission.add.controlobjective=
sosa.signature.permission.add.risk=
sosa.signature.permission.add.control=
sosa.signature.permission.add.test=
Remove the name of the group for which you want to revoke signing privileges from the
end of the line.
Members of the removed group would no longer be able to add signatures to the
compliance object type.
4.
5.
6.
Repeat the process for each group and compliance object type you want to revoke.
Save the changes to sosa.properties and exit the text editor.
Restart the SOX Express server to activate the new settings.
Automatic Signatures
Automatic signatures are applied to a compliance object as a result of a workflow task. A user is
assigned a task to create a signature. Completing the task results in a signature dialog box.
Once the user fills out the dialog, the new signature is created on the compliance object.
For instructions on setting up automatic signatures, see Enabling Signatures for SOX Express
Jobs on page 73.
Cascading Signatures
When a compliance object has a signature added to it, SOX Express provides the ability to
automatically apply the signature to all of the associated objects underneath the signed object
down the entire object tree. For example, signing a process would apply that signature to any
sub-processes, accounts, risks, controls, and tests associated with the process. This feature is
turned off by default, but can be enabled through the sosa.properties file.
To enable or disable cascading signatures for a compliance object type:
1.
2.
3.
4.
5.
6.

installation.
Find the line that corresponds to the compliance object type you want to disable
#sosa.signature.cascade.SOXBusEntity=SOXBusEntity,SOXAcc
ount,SOXSubaccount,SOXProcess,SOXSubprocess,SOXControlOb
jective,SOXRisk,SOXControl,SOXTest
#sosa.signature.cascade.SOXAccount=SOXSubaccount,SOXProc
ess,SOXSubprocess,SOXControlObjective,SOXRisk,SOXControl
,SOXTest
#sosa.signature.cascade.SOXSubaccount=SOXSubaccount,SOXP
rocess,SOXSubprocess,SOXControlObjective,SOXRisk,SOXCont
rol,SOXTest
#sosa.signature.cascade.SOXProcess=SOXSubprocess,SOXCont
rolObjective,SOXRisk,SOXControl,SOXTest
#sosa.signature.cascade.SOXSubprocess=SOXSubprocess,SOXC
ontrolObjective,SOXRisk,SOXControl,SOXTest
#sosa.signature.cascade.SOXControlObjective=SOXRisk,SOXC
ontrol,SOXTest
#sosa.signature.cascade.SOXRisk=SOXControl,SOXTest
#sosa.signature.cascade.SOXControl=SOXTest
#sosa.signature.cascade.SOXTest=
The object names after the equals sign are the compliance objects that will be signed
automatically when a signature is added to a compliance object of the appropriate type.
To enable cascading signatures, remove the comment character (#) from the beginning
of the line(s) you want to activate.
To disable cascading signatures after they have been enabled, add the comment
character (#) to the beginning of the line(s) you want to activate.
Removing a compliance object type from the list will remove the object from the
cascade. A signature will not be automatically created for the object type.
Enabling and Disabling Locks

Important Note: If locking is enabled, the cascading signatures setting must be turned off.
Cascading signatures and locks cannot be enabled at the same time, or you may see some
unexpected results.
Whether a lock is created when a signature is added is controlled by a setting in
sosa.properties. When the setting is active, adding a signature to a compliance object will also
create a lock on the object that prevents further changes from being made to the compliance
object and any object associated with it. Revoking a signature will remove the associated lock.
The setting is signature.autolock=. A value of true activates the locking behavior, and a
value of false deactivates it.
Note: When the locking feature is enabled, users can only create signatures on items to which
they have Write permissions.
See the Signing Off On Compliance Objects section of the SOX Express Users Manual for more
information on locking behavior.
The Lock and Unlock Permissions

Locks may also be applied to compliance objects without the use of signatures. If the Lock
application permission is granted to a group, the group can create a lock on any compliance
object to which they have Write permissions (as long as they also have write permissions to all
of the objects associated compliance objects down the hierarchy).
The Unlock permission allows a user to unlock any locked compliance object, as long as he has
Write permission to the object and all associated objects in the hierarchy.
Unlocking a compliance object using the Unlock button does NOT revoke the signature.
Locking Access Privileges

By default, Read permission is required in order to be able to lock a compliance object. This
setting can now be configured through a new property in the aurora.properties file named
allow.locking.read.access. This property is set to false by default.
When set to true, users with Read access to a compliance object will be able to lock the
compliance object by adding a signature. The default value of false requires that users have
at least Write access to a compliance object before they are allowed to lock it.
Enabling Workflows for SOX Express Objects 71
Enabling Workflows for SOX Express

Objects
About Enabling SOX Express Workflows
SOX Express provides the capability to start jobs (workflows) that are attached to specific SOX
Express compliance objects. This allows users to create workflows that apply to certain SOX
Express compliance objects, such as accounts or processes, and assign tasks.
Note: This section assumes that you already know how to create jobs and job types, as
described in the Managing Jobs and Job Types chapter of the OpenPages User Manual. The
OpenPages User Manual can be found in the docs directory of your OpenPages installation.
Pre-requisites for Starting SOX Express Jobs

In order to start a job from within the SOX Express user interface, the following pre-requisites
must be fulfilled:
The SOX Express user who is responsible for starting jobs must have the Start Jobs
application permission.
The job type to be started must be owned by the SOX Express user or a group to which
the user belongs.
Enabling a job type to be started from a compliance object requires access to OpenPages. Make
sure you have an OpenPages user name with the Manage Job Types application permission
when attempting to enable a job type.
Enabling a Job Type

Note: These steps can also be accomplished during the job creation process.
To enable a new or existing job type to be started from a SOX Express compliance object, you
will need to accomplish the following steps:
1.
2.
3.
4.
5.
6.
Log into the OpenPages server with a user name that has privileges to start and edit
jobs and job types.
Click the My Jobs link in the Action menu. The My Jobs page is displayed.
Click the View Job Types button at the top of the page. A list of Job Types is
displayed.
Choose the job type you wish to enable and click its name. The Job Type Details page is
displayed.
Click the Edit... button on the Properties table. The Edit Job Type Properties page is
displayed.
Click New and add a new Single File property with the name of the SOX Express
compliance object type for which you want the job type activated. The name of the
compliance object type must match a value in the following table and is case-sensitive.
Note: You do not need to specify any values except for the name of the property.
Enabling Workflows for SOX Express Objects 72
Content Type
Compliance Object
SOXAccount
Accounts
SOXBusEntity
Business Entities
SOXControl
Controls
SOXControlObjective
Control Objectives
SOXDocument
Associated Files
SOXProcess
Processes
SOXRisk
Risks
SOXSubaccount
Sub-Accounts
SOXSubprocess
Sub-Processes
SOXTest
Control Tests
7.
Add a Single File property for each compliance object type you wish to enable. When
you are finished adding properties, click Save to save your changes and return to the
Job Type Details page.
Jobs of the selected job type can now be associated with compliance objects of the type
specified in each Single File property.
Configuring Job Behavior 73
Configuring Job Behavior

Overview of SOX Express Jobs
When you create jobs and associate them with SOX compliance objects, there are certain
characteristics you can modify to add additional functionality to the workflow capabilities of
SOX Express.
The following sections detail the modifications you can make to SOX Express jobs and tasks:
Enabling Signatures for SOX Express Jobs on page 73

Assigning Job Tasks Based on Object Properties on page 73
Attaching Reports to Workflow Tasks on page 75
Enabling Signatures for SOX Express Jobs

To create a signature event for a job started from a SOX Express compliance object, create a
task in the job with an output arrow (exactly) labelled Signoff. When users complete the task,
they will be prompted to enter a signature which will appear in the Signoff table in the
compliance objects Details page.
Assigning Job Tasks Based on Object Properties

Note: This is an advanced topic, and should only be attempted by a user already familiar with
the SOX Express and OpenPages systems.
SOX Express supports the ability to determine the correct user to assign workflow tasks to by
looking at properties of the compliance object used to start the job.
For example, you can have a custom field on a Process called Reviewer, and list the user
name of the person responsible for reviewing the account. If you start a review job from that
process, the job can read the value of the Reviewer field and assign a review task to that
user. Otherwise, you would have to modify the job type each time before you ran it and
reassign each task to the proper user or group.
The steps involved in setting up automatic user assignment are:
Plan out the needed user roles and names for the job type.
Modify the job type and add the correct properties.
Set up a Custom Java Action Set to extract the user names and insert them into the
proper places in the tasks.
Create custom fields in the SOX Express object for the user names.
Planning Ahead
Before beginning the job type modification procedure, plan out what user roles and
assignments you will need to define. This is best done ahead of time.
Before you begin to make your changes, you should know in which field the name of the task
owner will be stored, and what the name of that field will be.
For our example, we will create a Reviewer role, and the field containing the name of the user
will be Process Reviewer.
Modifying the Job Type Properties

Once you have determined which user roles you will want to automatically assign, you must
modify the job type to create some properties with which to hold the user information once it is
gathered from the compliance object. You can also complete this step during the job type
creation process in the Edit Properties step, if desired.
In this procedure, we will create two new properties for the Job Type. These properties are
named TaskOwner and PropertyName. TaskOwner is where the retrieved name of the
assignee will be stored, and PropertyName identifies the field name where the name of the user
will be found. You will need to create these properties for any job where you wish to use
automatic user assignment.
To modify the job type:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
From the Home page, click on the My Jobs link in the Action menu. The list of currently
active jobs is displayed.
Click the View Job Types button at the top of the screen. A list of job types is
displayed.
Click the name of the job type you wish to modify. The Job Type Details screen is
displayed.
Click the Edit button under the Properties section, The Edit Job Type Properties screen
is displayed.
Click the New button on the right-hand side of the page.
Select Single File from the dialog box and click Ok.
Enter the compliance object type which this job will be activated from. For a list of
compliance object types, see the section Enabling a Job Type on page 71.
If you wish to enable the job for more than one compliance object type, repeat steps 5
through 7 for each object type.
Click the New button on the right-hand side of the page.
Select Simple String from the dialog box and click Ok.
Enter TaskOwner as the name of the property and a valid group name for the Default
Value and click the Apply button. The property is added to the list of properties for the
job type.
Repeat steps 9 and 10, and enter PropertyName into the Name field, and the name of
the property field where you will set the user name into the Default Value field. (For our
example, Default Value would be set to Process Reviewer.)
Click the Apply button to add the PropertyName property to the list of properties.
Click Save to save your changes and return to the Job Type Details page (or the Edit
page, if you are currently creating a new Job Type).
Modifying the Job Task

Once the custom properties have been added to the job type, you must create a Java Action to
pick up the user name from the compliance object field and store it in the TaskOwner property
you just defined. Finally, you must modify the task to use the Java Action you created and
assign the task to the TaskOwner property.
Create the New Java Action

1.
From the Details page of the job type you want to modify, click the Edit button in the
Tasks table. The Edit Tasks page is displayed
Note: You do not need to complete Step 1 if you are currently creating the job type.
Click Next from the Edit Job Type Properties to display the Edit Tasks page.
2.
3.
4.
Click the Java Action Sets button on the right-hand side of the shortcut bar. The
Define Java Action Sets dialog box is displayed.
Click the New button to display the Define Java Action Set dialog.
In the Name field, type GetOwnerSet and click the New button to create a new Java
Action.
5.
6.
7.
8.
Fill out
the fields as follows:

Action Name: GetOwner
Description: <leave blank>
Class name:
com.openpages.aurora.service.workflow.actions.GetMetaDataAction
Method to execute: getPropertyAsString
Store Return Value as: TaskOwner
There are two parameter properties to set.
a. Set the Single File property to the value of the Single File property type that
identifies which compliance object type the job will be associated with.
b. Set the Simple String property to PropertyName.
Click Apply to save your settings, then click Ok to close the dialog.
Click Close to close the Define Java Action Sets dialog. You are returned to the Edit
Tasks page.
Modify the Task Properties

1.
2.
3.
4.
5.
Right-click on the task to be assigned and select the Properties menu choice. The Task
Properties dialog is displayed.
Click the Actions tab and select GetOwnerSet for the value of Upon reaching this
node: .
Click the General tab and select <TaskOwner> as the Assigned To value.
Click OK to return to the Edit Tasks page.
Click Save to save your changes and return to the Job Type Details screen.
Creating the Compliance Object Custom Property

The final step to activate user assignment is to create the property field for the SOX Express
compliance object. This is the field you will use to enter the user name of the person the task
will be assigned to.
Follow the steps outlined in the section Modifying Compliance Objects on page 92 to add a
new field to your SOX Express compliance object.
Note: Make sure the name of the new field exactly matches the value of the PropertyName
custom property. In our example above, the name of the new field would have to be Process
Reviewer.
Attaching Reports to Workflow Tasks

Overview
SOX Express Express allows reports to be automatically attached to tasks within a workflow.
Clicking on the name of an attached report runs the report and displays the results in a new
window.
Adding a Report to a Workflow Task

To attach a report to a workflow task:
1.
2.
3.
4.
5.
Log into the OpenPages application as a user with the Manage Job Types permission.
Click on My Jobs in the Action Menu to display a list of all of your running jobs.
Click on the View Job Types button to display a list of job types.
Click the name of the Job Type you wish to edit to display the Job Type Details page.
Under the Tasks section, click the Edit button to view the Create Tasks page for the job
type.
6.
7.
8.
9.
10.
11.
12.
13.
Right-click the name of the task to which you want to add a report and click the
Properties menu selection. The Edit Task Properties page is displayed.
Click the Publishing tab to display the publishing settings for the task. This tab
displays a list of the reports that will be attached to the task when the task is reached.
Click the Add button to display a file browser.
Navigate to the folder containing the report page you wish to attach to the task. Click
the name of the folder to display the contents in the right-hand pane.
Select the report(s) you wish to attach to the task. Control-click to select multiple
reports within a single folder.
Click OK to add the reports to the task and return to the list of attached reports. The
selected reports are now listed in the window.
Once you have added all of the reports you want, click OK on the bottom of the page to
close the Edit Task Properties window and return to the Create Tasks page.
Click Finish at the bottom of the Create Tasks page to save your changes.
Removing a Report from a Workflow Task

To attach a report to a workflow task:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Log into the OpenPages application as a user with the Manage Job Types permission.
Click on My Jobs in the Action Menu to display a list of all of your running jobs.
Click on the View Job Types button to display a list of job types.
Click the name of the Job Type you wish to edit to display the Job Type Details page.
Under the Tasks section, click the Edit button to view the workflow diagram for the job
type.
Right-click the name of the task that has the report you want to delete and click the
Properties menu selection. The Edit Task Properties page is displayed.
Click the Publishing tab to display the publishing settings for the task. This tab
displays a list of the reports that will be attached to the task when the task is reached.
Select the name(s) of the report you are removing and click the Remove button.
Once you have removed the desired reports, click OK on the bottom of the page to
close the Edit Task Properties window.
Click Finish at the bottom of the Create Tasks page to save your changes.
Using Interactive Reports with Workflow Tasks

In order to use reports with interactive properties, simply attach the report as normal to a
workflow task. When the report is run, the report will prompt the user for values for the
interactive parameters.
If you have an interactive report parameter with the same name as a job property, the value of
the job property will be passed to the report as a string in the report.
The following limitations apply to the use of autofilling interactive report parameters with job
properties:
No attempt to validate that the job property and interactive report parameter are the
same data type (e.g. string, file path, enumerated list)
If a single interactive parameter matches the name of a job property, the user will not
be prompted to provide values for any other interactive parameters. If they do not
match job properties, they will be submitted to the report with blank entries. This may
cause the report to fail, depending on the report parameter.
Enabling Optional Reporting Tools 77
Enabling Optional Reporting Tools

Overview
In order to use the reporting capabilities of an optional reporting tool (such as
CommandCenter or Crystal Reports, you must configure and populate the reporting schema
with your current SOX Express data. The following sections will explain how to configure and
populate that database instance using the tools provided with Oracle and SOX Express.
This functionality replaces the orginal Exporter tool.
Differences From the Exporter Tool

The following compatibility areas exist between the current tool and the previous OP Exporter
tool:
Exposes the information about the nesting relationship between parent and child
objects in the relationship tables (also known as roll-up tables and transitive closures).
The OP Exporter tool does not preserve this information, making it challenging to create
generic drill-down reports.
Presents multi-valued properties as separate tables, as opposed to a single commaseparated list (a multi-valued roll-up). Presenting information in a single list makes
searching for objects that fall into more than one category more complex and requires
editing the filtering considerations by hand.
Accounts and sub-accounts, as well as processes and sub-processes, are treated as
separate content types (reflecting the actual object hierarchy in SOX Express). The OP
Exporter blended each set together and exposed them as a single content type.
Removes extraneous information from the master relationship table
(SX_ASSOCIATION). The OP Exporter required additional columns to be present in the
master relationship table (such as parent name, description, and loop-back URL).
Removes unnecessary self-to-self relationship tables that are only required for nested
compliance objects of the same type.
Changed the syntax of the nesting path value to a concatenated list of the names of all
the superior objects of the same type from top to bottom, and the name of the object
itself. The OP Exporter did not include the name of the object itself, causing top-level
objects to have a value of NULL.
Configuring the Reporting Metadata

Before the dynamic part of the SOX Express reporting schema can be created, the configuration
tables must be populated. Populating the configuration tables is a manual process. To simplify
the configuration process, an Oracle package named OP_REPORT_MGR is included with SOX
Express, along with two SQL scripts. The SQL scripts demonstrate how to load a reporting
configuration that corresponds to the standard SOX Express schema shipped with SOX Express.
Note: If you have customized your SOX Express schema, you will have to customize the SQL
scripts to reflect the changes you have made in your schema.
About the Configuration Tables

The SOX Express reporting schema includes a set of permanent tables that store the
configuration tables used by the OP_REPORT_MGR package to dynamically generate and
populate the rest of the reporting schema. The following tables are used to store configuration
information for the SOX Express reporting schema.
RPT_OBJECTS
The RPT_OBJECTS table is used to register the names of the database objects that
represent resources corresponding to registered content types. It also defines that
physical types of the database objects - views, materialized views, or tables. It allows
specifying tablespaces to store the database objects and their indices.
RPT_OBJ_COLUMNS
The RPT_OBJ_COLUMNS table is used to define the mapping between the properties
associated with a content type and the database object columns representing them,
column aliases, and and their physical order. It also allows the defining of functionbased columns by specifying the data transformation of the property values by means
of the supported macro keywords or a user-supplied function.
RPT_RELATIONS
The RPT_RELATIONS table is used to register object-to-object relationships. Database
objects representing relationships can be either materialized views or tables, depending
on the type of the master object. It can also specify column aliases for the parent and
child identifiers.
RPT_LEVEL_LABELS
The RPT_LEVEL_LABELS table is used to assign a string label to a particular level in the
hierarchy of jobects of the same type. For example, business entities can be nested,
and assigning a label to each level of nesting (Division, Department, Workgroup, etc.)
allows a better sense of level than Level 3 Entity.
The following diagram represents the relationship of the configuration tables.
About the Reporting Schema Scripts

SOX Express ships with two SQL scripts that demonstrate how to use the OP_REPORT_MGR
package to load the reporting configuration. By default, the scripts are configured to support
the default SSS (SOX Standard Schema) shipped with SOX Express.
The supplied scripts are:
ReportingSchema_Core.sql
Cleans up the reporting schema configuration tables

Registers the database objects to represent the SOX-specific content types and sets
their properties. The default database object is a materialized view.
Registers the columns that represent the core (system) attributes common to resources
of all content types in the system.
Registers the relationships between the various tables.
Registers the level labels for the content types that can be nested.
ReportingSchema_ProcessCentric_Delta.sql
Registers the remaining extended attributes defined in the SSS.
Note: The ReportingSchema_ProcessCentric_Delta.sql script only needs to be run the first time
you load the configuration into the reporting schema. Subsequently, it will only need to be run
if the schema of the SOX Express is modified in some way.
Executing the Configuration Scripts

To configure the reporting schema, log in as the openpages user and manually run both scripts
in SQL*Plus on the Oracle server machine in the following order:
sqlplus> ReportingSchema_Core.sql;
sqlplus> ReportingSchema_ProcessCentric_Delta.sql;
Customizing the Reporting Schema Configuration

To modify the reporting schema configuration, you can use any of the following methods:
Changing the supplied scripts

You can edit the supplied scripts and do a complete reload of the configuration data.
You can repeat this process as many times as necessary, as long as you run both
scripts - first loading the core attributes, and then the extended attributes.
Incrementally adding new content types and attributes

You can create additional scripts using the existing ones as a reference to register
additional content types or additional attributes for already registered content types.
Editing data directly in the database

In some cases, it might be easier to make minor changes or test new settings by
editing the contents of the configuration tables directly. Only experienced DBAs should
attempt this procedure, however, as the risk of user error is prominent.
Naming Restrictions
When customizing your schema configuration or contents, the following naming restrictions
must be followed: Object (table, view, or materialized view) and column names must be 30
characters or less and must be valid Oracle names (containing only alphanumeric characters,
dollar sign($), hashes(#), and underscores(_).
Mixed case names, names containing spaces, and international characters are not supported.
Object names must be unique in the application user schema. Column names must be unique
within the scope of a single object.
Supported Macro Keywords

Currently, the following macro keywords can be used to specify the data transformation of the
property values inside the configuration tables.
[FriendlyName] - applies to the resource name, resulting in the original resource name
with the extension removed.
[SoxUrl<;hostname:port>] - applies to the resource ID, resulting in the URL to view
the resource properties (the Details page) in the SOX Express user interface.
Note: If the hostname and port information is omitted, the SoxUrl defaults to
localhost:7009. If you are using third-party reporting tools such as CommandCenter
or Crystal Reports, you must modify the macro to explicitly specify the host server
name and port of the SOX Express application server. For load-balanced configurations,
you can specify different values in the hostname and port for different content
types.
[DelimitedList] - applies to the multi-valued properties, resulting in a comma-separated

list of values.
[LockStatus] - applies to the resource ID, resulting in an indication whether there is a
specific lock on the resource. This does not include checked-out locks.
[NestingPath] - applies to the resource ID of the nested content types (business
entities, sub-accounts, and sub-processes), resulting in a concatenated string of the
friendly names of the resource and all its subordinate objects of the same type.
[NestingLevel] - applies to the resource ID, resulting in a numeric value representing
the object level in the hierarchy of nested objects of the same type.
[NestingLabel] - applies to the resource ID, resulting in a value that represents the
nesting level.
If any of the columns for a given content type use one of the Nesting* macros, the resulting
database object will contain a level-based hierarchy representation, where each level of nesting
is represented by a column. The extra columns are named according to the level labels defined
for the corresponding content type.
If no level labels were defined for a given level, the column will be named as LEVEL<#> (e.g.
LEVEL1, LEVEL2, etc.)
Note: It is strongly recommended that you define level labels to accommodate the expected
depth of object nesting for a given implementation, because the algorithms that populate the
reporting schema rely only on the configuration data and do not validate whether the real data
has additional levels of nesting than were originally declared.
The following picture shows a table with the nesting and level-based hierarchy columns:
Populating the Reporting Schema

After loading the reporting schema configuration, you can create and populate the dynamic
portion of the reporting schema by executing the supplied command file (Refresh-ReportingSchema.cmd) and providing the required input parameters.
Note: For the Refresh-Reporting-Schema.cmd file to work correctly, the Refresh-ReportingSchema.sql file must be located in the same directory as the command file.
To populate the reporting schema:
1.
2.
3.
Open a command window on the Oracle database server.

Navigate to the directory containing the Refresh-Reporting-Schema.cmd batch file.
Execute the Refresh-Reporting-Schema.cmd file using the following syntax:
Refresh-Reporting-Schema.cmd
<OracleUserName> <OracleUserPassword> <OracleAlias>
<ReportingPeriodValue> [<AddReportingPeriodColumn>
[<ReportingPeriodColumnName> [<BackwardCompatibilityMode>]]]
where:
<OracleUserName> is the name of the Oracle user account used by the SOX Express
application to connect to the database. This is a required parameter.
<OracleUserPassword> is the password of the Oracle user account. This is a
required parameter.
<OracleAlias> is the Oracle Net Alias, a friendly Oracle instance system identifier or
connection string. Usually this is the same as the SID. This is a required parameter.
<ReportingPeriodValue> - is a value to be inserted into the Reporting Period
column. This is a required parameter. Can be any arbitrary string. If the string contains
spaces, it must be enclosed with double quotes. The special keyword auto can be
used to populate the reporting period column with a timestamp representing the time
that execution of the Refresh-Reporting-Period.cmd was started. Specifying a value of
no, none, null, or nothing will cause the default value of
<AddReportingPeriodColumn> to flip to no, and a reporting period column will not be
added unless the <AddReportingPeriodColumn> is explicitly set to Yes.
<AddReportingPeriodColumn> - indicates whether the reporting period column
should be added to all objects created during the reporting schema refresh. Allowed
values are yes and no. This is an optional parameter that defaults to yes if it is not
included in the parameter list. The reporting period column can be used to uniquely
identify data produced by different reporting schema refresh sessions, if the user
chooses to load the data into a dedicated data warehouse.
<ReportingPeriodColumnName> - specifies a physical name for the reporting
period column. Defaults to none. When the default value is used, the reporting period
column is named REPORTING_PERIOD. This is an optional parameter.
Note: When the Refresh-Reporting-Schema.cmd is run, it will automatically turn on
Oracle Statistics for the following tables: all tables beginning with SX_, and the
EFFECTIVE_RIGHTS table.
Checking the Results of the Reporting Schema Refresh

On every execution, the command line utility creates a new log file named in the format of
Refresh-Reporting-Schema-YYYY-MM-DD#HH-MM-SS.log.
After the command executes, review the file for any possible errors and to get information
about what input parameters were used for a given execution session, as well as the time it
took to refresh the reporting schema.
Below is a sample of a successful reporting schema refresh:
Refreshing Reporting Schema...
Execution started at 2004-10-13 16:25:03.53
Input parameters:
Add reporting period column: [yes]
Column name: [Default/Not specified]
Column value: [Auto generated/not specified]
Backward compatibility mode: [Not requested]
Execution finished at 2004-10-13 16:52:02.73
Elapsed time: +000000000 00:26:59.209000000
PL/SQL procedure successfully completed.
The sample log below illustrates the errors logged when the reporting schema configuration
was not loaded or was incomplete:
ERROR at line 1:
ORA-20100: Reporting schema metadata are not loaded
ORA-06512: at "OPENPAGES.OP_EXPORTER", line XXXX
ORA-06512: at line 1
This sample log corresponds to a situation where a reporting schema refresh is attempted, but
another schema refresh session or compliance object reset event is in progress:
ERROR at line 1:
ORA-20100: Another reporting schema refresh operation in progress
ORA-06512: at "OPENPAGES.OP_EXPORTER", line XXXX
ORA-06512: at line 1
Synchronization Control
Because during the reporting schema refresh database objects can be dropped and created,
this operation is implemented as a single instance task. To enforce that no more than one
refresh operation can be executed at any given time, the RPT_LOCK table is used.
As the reporting schema refresh and the compliance object reset operations both use and
modify a common subset of the database objects (namely the NODES table and the
EFFECTIVE_RIGHTS materialized view), those operations cannot be executed at the same time.
The RPT_LOCK table can be used to verify if reporting schema refresh is in progress and its
current status. If refresh is being executed, the table will contain a single record, otherwise the
table will be empty. For more information about the table layout and usage sample refer to the
diagram below:
The following is an example of checking for the currently running reporting schema refresh jobs
and their status using SQL*Plus:
column
column
column
column
column
initiator format a40

active_module format a40
start_time format a30
entry_time format a30
last_heartbeat format a30
select * from rpt_locks;
Exporting Data to the Reporting Database Instance

After the contents of the reporting schema are created (refreshed), it must be copied to a
dedicated reporting instance. This is a two-step process - first the data must be exported
outside the live application instance, and then loaded into the dedicated reporting Oracle
instance.
The following sections will explain the procedures required to export the reporting schema to
the reporting instance.
Note: To run the Export-Reporting-Schema.cmd command file, the Generate-ExportParams.sql script must be located in the same directory as the command file.
Exporting the Reporting Schema Contents

To export the required reporting schema database objects:
1.
2.
Open a command prompt on the database server machine and navigate to the location
of the Export-Reporting-Schema.cmd command file.
Execute the Export-Reporting-Schema.cmd file with the following syntax:
Export-Reporting-Schema.cmd
<OracleUserName> <OracleUserPassword> <OracleSID> <NLS_LANG>
where:
<OracleUserName> is the name of the Oracle user account used by the SOX Express
application to connect to the database. This is a required parameter.
<OracleUserPassword> is the password of the Oracle user account. This is a
required parameter.
<OracleSID> is the Oracle instance system identifier or service name. This is a
required parameter.
<NLS_LANG> is the national language setting to be used for the data export session.
This is a required parameter.
Note: In order to run the export command successfully, SQL*Plus and the Oracle EXP utility
must be installed on the Oracle database server.
After completion, the command line utility creates four files:
reporting-schema-exp-parameters1.txt - contains the export parameters used by the

EXP utility.
reporting-schema-exp-parameters2.txt - also contains the export parameters used by
the EXP utility.
rpt-exp_YYYY-MM-DD#HH-MM-SS.log - provides statistics about the data exported and
any error information.
rpt-exp_YYYY-MM-DD#HH-MM-SS.dmp - export file containing data and object
definitions for the reporting schema.
Importing the Reporting Schema Contents

Importing the data is a two-step process. First, you must import the contents, constraints, and
indexes for all of the reporting schema tables, except for the RPT_OBJECTS, RPT_RELATIONS,
EFFECTIVE_RIGHTS, ACTORINFO and FOLDERS tables.
Then import the contents and indexes for the above-mentioned tables.
Note: The constraint definitions for those tables should not be imported, as foreign keys on
those tables reference other tables which are not part of the reporting schema and are not
exported.
To simplify the importing process, you can use a copy of the reporting-schema-exp-params.txt
file to create a parameter file for the Oracle IMP utility.
For information about the format of Oracle parameter files for the EXP/IMP utilities consult your
Oracle product documentation.
Note: It is possible to import the entire data dump file and review the reported errors.
However, only the foreign key creation errors for the above-mentioned tables can be safely
ignored.
Currently, in order to load updated data, the existing database objects have to be dropped. As
part of the SOX installation, the AuroraDBDelete.sql script is supplied, which can be used to
drop all the objects in the user schema. This script can be executed in SQL*Plus.
Note: Exercise caution when executing the script, as the script removes all objects owned by
the currently connected user.
Once the contents are imported successfully, the reporting schema data source is ready to be
accessed by the third-party query engine.
Changing the Database Passwords 85
Changing the Database Passwords

Overview of Changing the Database Passwords
Occasionally, you may need to update or change the Oracle or WebLogic system password.
When you do, you will also need to update the password in various places inside SOX Express
configuration files and property files.
Changing the Oracle Password

The default Oracle username/password used by SOX Express is openpages/openpages. To
change the password, you will have to modify the following files:
config.xml
config.xml.keep
aurora.properties
autoexnt.bat
op-backup-recovery.env
Note: Be sure to backup each file before making any modifications.

To change the default Oracle username/password:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
Stop the OpenPages Application Server.

Change directories to the directory <WL_HOME>\config\OpenpagesDomain.
Open the file config.xml in a text editor.
Search for the string JDBCConnectionPool and change the value for the attribute
Password to your new password. The password will be encrypted automatically the
next time the service accesses the file.
Save the file and exit the text editor.
Repeat the above steps for the config.xml.keep file.
Change directories to the <WL_HOME>\aurora\conf directory.
Open the aurora.properties file in a text editor.
Search the file for the string database.PASSWORD.
Change the value following the equals sign to the new password.
Save your changes and exit the editor.
Change directories to the c:\Windows\System32 directory.
Open the autoexnt.bat file in a text editor. In the first java command, you will see the
Oracle password (next to the port number at the end of the string).
Change the string to the new password.
Change directories to the <WL_HOME>\aurora\bin directory.
Open the op-backup-recovery.env file in a text editor.
Find the line that starts DB_OP_PWD and change the value of the variable to the new
password.
Restart the OpenPages Application Server.
Changing the WebLogic Password

In order to change the password for the BEA WebLogic server, you will first need to change the
password inside WebLogic, and then change all references to that password inside the SOX
Express environment.
Changing the Password in WebLogic

To update the WebLogic password in BEA WebLogic:
1.
Log onto the application server and stop all the SOX Express application services except
OPAdminWLS.
2. Log into the BEA WebLogic administration console (http://<servername>:7001/
console).
3. Select the Compatibility Security|Users option in the left-hand menu.
4. On the Users screen, there is an option to change the password.
5. Enter system (without the quotes) into the Name field.
6. Enter the current system password in the Old Password field, and the new password in
the New Password field.
7. Click the Change button to save your changes.
8. A link titled Click here to save these changes to the realm implementation. will appear
in the upper right of the Users window. Click the link to save the changes to the realm.
9. A confirmation dialog will appear. Click Continue and close the Administration Console.
10. Navigate to the \bea\weblogic81\config\OpenpagesDomain directory and open the
boot.properties file using a text editor
11. Set password to the new password in clear text. This will get encrypted the next time
the server starts.
Changing the Password References in SOX Express

To modify all references to the BEA WebLogic password in SOX Express:
1.
2.
3.
4.
5.
6.
Shut down the OPAdminWLS service. (This assumes that the other services are already
stopped from changing the password in WebLogic. If the other SOX Express services
are running, shut them down also.)
Navigate to the <WL_HOME>\config\OpenpagesDomain directory.
Edit the following files:
startWebLogic.cmd
startPublishwebServer.cmd
startOPAppServer.cmd
startSOSAServer.cmd
In each file, find the following line:
set WLS_PW=<old-password>
Replace the old password with the new system password for WebLogic.
set WLS_PW=<new-password>
In each .cmd file, change the password parameter in the JAVA command to reflect the
new password:
-Dweblogic.management.password=<old-password>
to
7.
8.
-Dweblogic.management.password=<new-password>
Finally, edit the password.ini file and change the old password to the new one.
Changing Your Server IP Address

When changing the IP addresses of the application and database server and keeping the
machine name the same, you will have to delete the .wlnotdelete folders in your SOX Express
installation directory.
The folders are located under the \bea\weblogic81\config\OpenpagesDomain directory, in the
\applications folder, and in the four folders that correspond to the four servers. Before
removing the folders, you will need to shut down all application servers and then remove all
five folders.
88
4
Modifying SOX Express
Behavior
This chapter provides information about administering the SOX Express application, including
adding and removing SOX Express users, report administration, and adding custom fields to
SOX Express compliance objects.
This chapter contains the following topics:
Customizing the Overview Pages on page 89

Modifying Compliance Objects on page 92
Additional Modifications on page 108
Using Netegrity SiteMinder on page 119
Customizing the Overview Pages 89
Customizing the Overview Pages

About Customizing the Overview Pages
SOX Express allows administrators to control which compliance objects are displayed in the
Entity Overview, Process Overview, and Account Overview pages. By modifying the settings in
the configTileDefinitions.xml file, compliance object types (risks, controls, etc.) can be removed
from the Overview pages.
In addition, you can toggle the shift-click Expand All behavior of the overview pages by
changing a configuration file setting.
The modifications to the overview pages are detailed in the following sections:
Modifying the Overview Page Definitions on page 89

Enabling/Disabling the Expand All Capability on page 90
Modifying the Overview Page Definitions

Once an object type is removed from the page definition, it will no longer be displayed in the
Overview page along with any object types that are associated with it.
For example, if you remove Controls from the Entity Overview page, they will no longer be
displayed as you expand the Entity Overview page. The ICDocumentation structure will appear
to stop at the Risk level. In addition, Tests and Test Results will no longer be displayed, since
the Controls they are associated with are not present in the Entity Overview page.
There are two things to keep in mind when modifying which compliance objects are displayed in
the Overview pages:
Compliance objects below the removed object type will not be displayed - think
carefully before removing an object type from an overview page.
Any changes to the Overview pages are applied to everyone in the system. There is no
way to restrict the modified view to a certain sub-set of users. All users will see the
same modified Overview page.
The custom definitions for the three Overview pages are kept in the configTilesDefinitions.xml
configuration file, located in the config\OpenpagesDomain\applications\sosa\WEB-INF directory
of your SOX Express installation.
You must have write access to the OpenPages server machine in order to modify the
configuration file.
Note: When modifying an Overview page, restrict your modifications to the
configTileDefinitions.xml file. This file overrides the default definition and will not be overwritten
during an upgrade procedure.
To modify an Overview page:
1.
2.
3.
Back up the existing configTileDefinitions.xml file.

Open the configTileDefinitions.xml file in a text editor.
Find the definition tag for the overview page you wish to modify. Search for:
account.overview to display the Account Overview definition
entity.overview to display the Entity Overview definition
process.overview to display the Process Overview definition
4.
5.
Each definition contains a commented-out putList statement which contains the

definition for the overview page. Uncomment the entire definition. The putlist
statement should look like the following:
<putList name="types.list" >
<add value="SOXBusEntity" />
<add value="SOXAccount" />
<add value="SOXSubaccount" />
<add value="SOXProcess" />
<add value="SOXSubprocess" />
<add value="SOXControlObjective" />
<add value="SOXRisk" />
<add value="SOXControl" />
<add value="SOXTest" />
<add value="SOXTestResult" />
</putList>
Find the line which corresponds to the compliance object type you want to remove and
comment it out. For example, to remove Risks from the overview page, modify the
definition to look like the following:
<putList name="types.list" >
<add value="SOXBusEntity" />
<add value="SOXAccount" />
<add value="SOXSubaccount" />
<add value="SOXProcess" />
<add value="SOXSubprocess" />
<add value="SOXControlObjective" />
<!-<add value="SOXRisk" />
-->
<add value="SOXControl" />
<add value="SOXTest" />
<add value="SOXTestResult" />
</putList>
Remember that removing Risks from the overview page will also remove Controls,
Tests, and Test Results. You do not need to comment out each type - merely the
topmost element.
Note: The order of the elements in the overview page definition does not determine the
order in which the object types are associated or displayed. For example, if you
commented out the SOXSubaccount line in the Account Overview definition,
processes that are associated with accounts would still be displayed, while processes
associated with subaccounts would not.
6.
Repeat the above steps for each overview page and save your changes. You must
restart the SOX Express server for the changes to take effect.
Enabling/Disabling the Expand All Capability

SOX Express allows users to press shift-click when clicking on the plus icon next to a
compliance object in order to expand all levels of the object hierarchy. This behavior is turned
off for the highest levels of the entity hierarchy (business entities and top-level folders).
In a large-scale system, users capable of viewing all of the objects in the compliance object
hierarchy can experience slow behavior when expanding all from the top levels of the hierarchy.
If you wish to enable the ability to expand all from the business entity and folder levels of the
entity hierarchy, add the following line to the sosa.properties configuration file, located in the
\sosa\conf directory of your SOX Express installation. You will have to restart the server after
making the changes.
expand.selection.enabled = true
To disable the functionality once you have enabled it, either remove the line or comment it out.
Modifying the Overview Node Cache

The sosa.properties file (located in the \applications\sosa\conf directory of your SOX Express
installation) contains a parameter that controls the number of objects that each node of the
overview page can contain for each user session.
To change the maximum number of nodes displayed in the Overview cache, modify the
following setting:
overview.node.cache.capacity=1000
If the number of nodes displayed exceeds the above setting, the additional nodes will not be
displayed. Each cached object requires 1600 bytes of memory.
After making your changes, you must restart SOX Express.
Modifying Compliance Objects 92
Modifying Compliance Objects

Overview of Modifying Compliance Objects
SOX Express allows administrators to add new properties to the various compliance objects
(business entities, accounts, processes, risks, etc.) involved in the internal controls
documentation project, as well as hiding existing properties. Each object has certain properties
already defined for it, such as Account Type, Transaction Volume, etc.
The following paragraphs provide a quick overview of the steps required to add a new field to a
compliance object.
Step One: Identifying the New Field
The first step is identifying what type of field you want to add to the object - what type of data
you intend to collect, and how that data will be selected and/or stored. SOX Express supports
many different types of fields, which will be explained in more detail in later sections.
Step Two: Defining the Field Properties
The next step is creating a new property bundle that contains the property definition of the new
field(s). The property definition stores the data entered into the field. It is recommended that if
you are creating more than one new field for a compliance object, you store all of the custom
property definitions in the same property bundle.
Step Three: Attaching the Property Bundle
Each type of compliance object (business entity, account, process, etc.) has a corresponding
content type that gathers all of the different property bundles used by the compliance object.
Once the new property bundle is created, it must be attached to the appropriate content type.
Step Four: Displaying the New Field
Once the property bundle for the new field is attached to the compliance objects content type,
the display definition of the object must be modified to include the new field. In this step, you
will determine where the new field will be displayed on the details page.
Step Five: Activating the New Field
Once the previous steps are completed, the SOX Express application must be restarted to
recognize the new field.
Example: Adding a New Text Field

During the following procedure, you will be shown an example of how to create a new text field.
Additional examples of adding property fields will follow the procedure.
The following instructions will allow users to add new custom property fields to compliance
objects.
Step One: Identifying the New Field

The first step when adding a new field is to examine what sort of field you want to add, and
which compliance objects you wish to modify. Planning your changes ahead of time helps to
minimize the necessary work, and perhaps prevent duplication of effort. Prior to beginning the
creation of the new field, you should identify the following information:
the affected compliance object - Which compliance object or objects will the new field
be added to?
the name - How will the new field be identified?
the label - What text will be displayed on the Details screen? This information will also
appear when adding and editing a compliance object.
the property type - What form input element (text field, text area, drop-down, etc.) will
be used to capture the data?
Example: Identifying the New Field

In our example, we wish to add a Process Owner, Account Owner, Control Owner, etc. to
each object. To do this, you would have to create a property bundle and a new field for each
compliance object type - one for accounts, one for processes, etc.
However, if we simply create an Owner field for all objects, we will only need to create one
property bundle for the new Owner field, and simply re-use later if we want to add it to each
compliance object type. This simplifies the work we have to do, so we will follow this approach.
For the purposes of this example, we will add it to the Account object.
So, we know that we want to apply the new field to the Account object. We need to determine
a name for the new field - well call it Owner. The name of the field is important, because it is
also the text that will appear next to the field when it is displayed, followed by a colon (:). Since
we chose to name the new property Owner, the text next to the new field will read Owner:.
We are only entering a name into the field, so the property type for this field will be Simple
String.
Step Two: Defining the Field Properties

The next step in adding a new field to a compliance object is to create a new property bundle
that will contain the definition of the new property (or properties) you wish to add. Each new
field requires a corresponding property. The property stores the information entered into the
new field.
Note: For additional information about property bundles, see the OpenPages User Manual.
To define the property for the new field:
1.
2.
Log into the OpenPages server as a user with Administrative permissions.

Click the Property Bundles link under the Administration heading in the left-hand
Action menu. The Property Bundles page is displayed.
Add Bundle
Button
3.
Click the Add Bundle... button. The Describe Property Bundle page is displayed.
4.
Enter a name and description for the property bundle in the respective fields.
For our example, the new custom property bundle will be called CustomFields. We will
use this name for the new property bundle in future steps. Replace CustomFields with
your property bundle name as necessary.
5.
Click the Next button. The Define Properties page is displayed.
New Button
Property
Definition
Area
6.
Initially, there are no properties defined for the bundle. To start defining properties,
click the New button. The Select Property Type page is displayed in a pop-up window.
The Select Property Type page enables you to select the type of information that the
property is going to contain.
For explanations of the different property types, access the online help or the
Openpages 5.0 User Manual.
7.
Select the desired property type and click the OK button. The Define Properties page is
displayed with new controls available and active in the property definition area.
For our example, we will choose the Simple String property type.
If at any point in the process you realize that you have made an error, you can click the
Reset button to clear all the fields. If you have accidentally selected the wrong
property type, you can click the New button again to select another type.
8.
Enter a name and description that you want to use for the property type. Names are
mandatory for all property types.
For our example, we will use the name Owner for our new property.
9. Enter the all other information that you need to specify for the property.
10. If you want the property to be required, meaning that the user must provide a value for
this property when the file is added to the system, click the Value Required checkbox
so that it is selected.
Since we want every account to have an owner, we will select the Value Required
checkbox for the Owner property.
11. When you have finished defining the property, click the Apply button to save your
changes and add the property to the bundle. The property is added to the property list.
Property
List
Delete
Button
Finish
Button
12. When you are finished defining properties for the bundle, click the Finish button. The
new property bundle is saved and is displayed on the Property Bundle page.
Example: Defining the Field Properties

So, in Step One, we created a new property bundle which we called CustomFields. We then
added a new Simple String property to the property bundle and named it Owner. We also
decided that the new fields value must be required when a new account is created or modified.
After saving our changes, it is time to attach the property bundle to the desired compliance
object (in this case, the Account object).
Step Three: Attaching the Property Bundle

The next step in the procedure is adding the newly created property bundle to the content type
for the compliance object we want to change. There is a content type for each compliance
object:
Content Type
Compliance Object
SOXAccount
Accounts
SOXBusEntity
Business Entities
SOXControl
Controls
SOXControlObjective
Control Objectives
SOXDocument
Associated Files
SOXIssue
Issues
SOXMilestone
Project Milestones
SOXProcess
Processes
SOXProject
Projects
SOXRisk
Risks
SOXSubaccount
Sub-Accounts
SOXSubprocess
Sub-Processes
SOXTask
Project and Issue Action Items
SOXTest
Control Tests
SOXTestResult
Control Test Results
To add the property bundle to a content type:

1.
2.
3.
4.
5.
6.
While logged into OpenPages with an administrative-level account, click the Content
types link under the Administration heading in the left-hand Action menu. The list of
available content types is displayed.
Click on the name of the content type you want to edit. The Details page is displayed.
Click the Edit button under the Property Bundle Information heading. The Assign File
Types and Property Bundles page is displayed.
Click the Add button on the list of property bundles. A list of available property bundles
is displayed.
Highlight the name of the custom property bundle you just created and click Ok to add
the property bundle to the content type.
Click Save to save your changes and return to the Details page for the content type.
Example: Attaching the Property Bundle

In Step One, we decided that we wanted the new Owner field to be added to the Account
object. We created a new property bundle called CustomFields in Step Two. Using the above
procedure, we now select the SOXAccount content type and add the new CustomFields property
bundle to the content type. If we wanted to use the new field in more than one compliance
object, we would repeat the above procedure for each object type.
Step Four: Displaying the New Field

The next step in the process of enabling your new property is to edit the
configTileDefinitions.xml file so that your new property is recognized by the SOX Express
application.
To activate the new property:
1.
Log in to the server machine and navigate to the following directory:

<weblogicdir>\weblogic81\config\OpenpagesDomain\
applications\sosa\WEB-INF
where <weblogicdir> is the home directory of your BEA WebLogic server installation.
2.

Note: Make sure you back up the configTileDefinitions.xml file before making any
changes.
3.
Find the definitions section for the compliance object you want to modify, as identified
by the string <object>.prop.body where <object> is the object you want to modify. For
example, if you are modifying an account, the string would be account.prop.body.
4. Remove the comment tags () from the object definition if this is the
first time you are modifying the object.
5. Modify the <putlist> tag to include the definition for the new property, as in the
example below:
<putList name="property.list">
<add value="account.property.accountType"/>
<add value="account.property.newProp"/>
</putList>
The order of the property definitions controls the order in which they will be listed on
the object Details page and in the Add and Edit pages. Insert the new property
definition into the spot where you want the property to be listed.
Make sure the name for the new property definition (i.e. account.property.newProp in
this example) does not inadvertently match another property definition already defined
for the object.
Note: When modifying the Business Entity definition (busentity.prop.body), you must
remove the three sample property definition lines from the sample business entity
definition. The lines to be removed are:
<add value="customer.busentity.property.newProp"/>
<add value="customer.entity.property.ExecutiveOwner"/>
<add value="customer.entity.property.PrimaryOwner"/>
6.
Add the definition tag for the new property after the <definition> end tag containing
the <putlist> tag, using the format of the example below. A sample definition tag can
also be found in the XML file. Portions of the example in bold text should be replaced
with text specific to your property.
<definition>
</putList>
</definition>
<definition name="account.property.newProp">
<put name="bundle.name" value="TestBundle"/>
<put name="property.name" value="AddedProperty"/>
</definition>
The string account.property.newProp should be replaced with the property definition

name you assigned in step 4. The string TestBundle should be replaced with the name
of your new property bundle. The string AddedProperty should be replaced with the
name of the new property you created in Step One.
Make sure you match the spelling and case of the property bundle and property name
exactly.
7.
Save the configTileDefinitions.xml file.
Example: Displaying the New Text Field

Now we are ready to insert the new field into the Account detail page. When we open the
configTileDefinitions.xml file, we locate the section that relates to the account compliance
object. That section looks like this:
<definition name="account.prop.body"
extends="icdocumentation.property.form.body">
<add value="account.property.accountNumber"/>
<add value="account.property.assertions"/>
<add value="account.property.sizeOfAccount"/>
<add value="account.property.transactionVolume"/>
<add value="account.property.importanceOfErrors"/>
<add value="account.property.susceptibilityToFraud"/>
<add value="account.property.recentChanges"/>
<add value="account.property.additionalInfo"/>
<add value="account.property.classification"/>

</putList>
</definition>
We decide that the owner should be listed first - before the Account Type: field. So, using the
text editor, we add the following line before the accountType line, like so:
<definition name="account.prop.body"
<add value="account.property.accountOwner"/>
<add value="account.property.accountNumber"/>
...
</putList>
In this example, weve named the new value account.property.accountOwner, but we could
have called it anything, as long as we create a property definition that shares the same name.
Now that weve added account.property.accountOwner as a property in the property list, we
need to add a definition for the property in the same file. Below the list of account properties,
there is a sample definition that looks like this:
<definition name="account.property.newProp">
<put name="property.name" value="Added Property"/>
<put name="field.length.maximum" value="128" />
</definition>
We copy the sample definition and paste it outside the comment markers (), so that
when the file is read by the server, it will not be ignored. We then modify the pasted definition
tag to look like the following:
<definition name="account.property.accountOwner">
<put name="bundle.name" value="CustomFields"/>
<put name="property.name" value="Owner"/>
<put name="field.length.maximum" value="128" />
</definition>
The first line is changed to match the name of the property value we added to the property list
- in this case, account.property.accountOwner. The bundle.name line is modified to include
the exact name of the property bundle we created in Step Two - CustomFields. The
property.name line is modified to include the exact name of the property we added - Owner.
Once the new field definition is added, we save our changes and exit the editor.
Step Five: Activating the New Field

Contact your SOX Express Administrator and have him restart the SOX Express application
server. Once the server is restarted, verify that the new property has been successfully added
by modifying an existing object and entering a value for the new property.
Note that existing objects of the type you modified will not display the new property when you
view the Details screen. However, when the object is edited, the new property will be displayed
correctly, including any default values. In addition, once the object is opened for editing the
Value Required attribute of the property will be enforced, if present.
Example: Adding a New Text Area Field

In this example, we will add a new text area field called Description of Failure to a test result.
In effect, the process is the same as adding a simple text field.
First, we create a new property bundle, which we give a unique name, such as
TestResultCustomFields. Then we create the property for the new text area. Single-line text
fields and multi-line text areas both use the Simple String property, so we create a new Simple
String property and name it Description of Failure. Remember that the name of the property
is also the text that will appear next to the new field when the Details page is displayed, so
check for typographical errors and spelling.
Once we save the new TestResultCustomFields property bundle, we need to edit the
configTileDefintions.xml file. Use the directions in Step Four: Displaying the New Field to open
the configTileDefinitions.xml file for editing, and find the Test Result definitions area, which
looks like this:

<definition name="testresult.prop.body"
<add value="testresult.property.date"/>
<add value="testresult.property.by"/>
<add value="testresult.property.result"/>
<add value="testresult.property.effective"/>
</putList>
</definition>

Uncomment the object definition by removing the comment tags () from
around the definition.
In this example, we want to put the Description of Failure field at the end of the list, so that it
is the last field displayed. Copy the last <add value... /> line and paste it in front of the
</putlist> tag. When you are finished, the section should look like this:
</putList>
</definition>
Modify the line to reference the new definition you will create for the new field. When you are
finished, the section looks like:
<add value="testresult.property.failure"/>
</putList>
</definition>
Now, we need to add the definition of the new field. Because we named the new value in the
previous step testresult.property.failure, the new definition will need to match this value
exactly. Here is a generic text area definition tag for you to copy and insert:
<definition name="account.property.newProp"
extends=textarea.property>
<put name="property.name" value="Added Property"/>
</definition>
The new definition should look like this when you are finished:
<definition name="testresult.property.failure"
<put name="bundle.name" value="TestResultCustomFields"/>
<put name="property.name" value="Description of Failure"/>
</definition>
If you wish to change the display parameters of the text area - the height and width of the
input area - you must add the following two lines to the definition:
<put name="column.size" value="80"/>
<put name="row.size" value="6"/>
If we wanted to change the Description of Failure field to be 80 characters wide and 6 lines
tall, the modified text area definition would look like this:
<definition name="testresult.property.failure">
<put name="bundle.name" value="TestResultCustomFields"/>
<put name="property.name" value="Description of Failure"/>
<put name="column.size" value="80"/>
</definition>
Once you save your changes and restart the SOX Express server, the new field will be displayed
in the Test Result details page.
Example: Adding a New Drop-down Selection Field

In this example, we will add a new drop-down selection field called Purpose of Control to a
control. Drop-down selections are useful when you have a field that has a finite set of known
values. They also make it easier to create reports based on the field value, because you can
accurately predict the values to look for, without worrying about idiosyncratic responses or
shorthand, such as Y instead of Yes.
ControlCustomBundle. Then we create the property for the new field. Drop-down selection
fields use the Enumerated String property type and the name for the new field will be
Purpose of Control. Remember that the name of the property is also the text that will appear
next to the new field when the Details page is displayed, so check for typographical errors and
spelling.
With an enumerated string property, you must specify the possible values in the property. We
will need three values for the property; well call them - Prevention, Identification, and
Error Recovery.
Type the three values into the Add value field under the Allowed Values section and hit Add
after each one. Because the vast majority of controls added into the system will deal with
Financial Reporting, click the drop-down next to the Default value heading and select
Financial Reporting. Then click the Apply button to save the new property. Click Finish to
save the new property bundle.
Once we save the new ControlCustomBundle property bundle, we need to edit the
configTileDefintions.xml file. Use the directions in Step Four: Displaying the New Field to open
the configTileDefinitions.xml file for editing, and find the Control definitions area, which looks
like this:

<definition name="control.prop.body"
<add value="control.property.classification"/>
<add value="control.property.documentationLocation"/>
<add value="control.property.controlType"/>
<add value="control.property.whoPerformsControl"/>
<add value="control.property.itDependent"/>
<add value="control.property.controlsTested"/>
<add value="control.property.walkthroughs"/>
<add value="control.property.controlEvaluation"/>
<add value="control.property.newProp"/>
-->
</putList>
</definition>

In this example, we want to put the Purpose of Control field at the end of the list, so that it is
the last field displayed. Copy the last <add value... /> line and paste it in front of the
EXAMPLE line. When you are finished, the section should look like this:
-->
</putList>
</definition>
<add value="control.property.Purpose"/>
-->
</putList>
</definition>
previous step control.property.COSO_Objective, the new definition will need to match this
value exactly. Here is a generic drop-down definition tag for you to copy and insert:
<definition name="task.property.actionPlanType">
<put name="bundle.name" value="custom.bundle"/>
<put name="property.name" value="custom.property.name"/>
</definition>
<definition name="control.property.Purpose">
<put name="bundle.name" value="ControlCustomBundle"/>
<put name="property.name" value="Purpose of Control"/>
</definition>
in the Control details page.
Example: Adding a New HTML Field

In this example, we will add a new HTML-enabled field titled Additional Comments to the
Control compliance object. HTML-enabled fields allow users to add HTML-encoded text in the
field. This can be useful for adding a link to additional documentation, or embedding a table of
results from an external report.
ControlCommentBundle. Then we create the property for the new field. HTML-enabled fields
use the Simple String property type and the name for the new field will be Additional
Comments. Remember that the name of the property is also the text that will appear next to
the new field when the Details page is displayed, so check for typographical errors and spelling.
Click the Apply button to save the new property. Click Finish to save the new property bundle.
Once we save the new ControlCommentBundle property bundle, we need to associate the
new bundle with the SOXControl content type (using the procedure in Step Three), and then
edit the configTileDefintions.xml file. Use the directions in Step Four: Displaying the New Field
to open the configTileDefinitions.xml file for editing, and find the Control definitions area, which
looks like this:



In this example, we want to put the Additional Comments field at the end of the list, so that it
is the last field displayed. Copy the last <add value... /> line and paste it on the next line.
When you are finished, the section should look like this:
</putList>
</definition>
-->
<add value="control.property.additionalComments"/>
</putList>
</definition>
-->
previous step control.property.additionalComments, the new definition will need to match this
value exactly. Here is a generic HTML-enabled field definition tag for you to copy and insert:
<definition name="sox.property.rich.text.example">
<put name="bundle.name" value="SOXRTF"/>
<put name="property.name" value="RTF"/>
<put name="display.type" value="rich.text.area"/>
<put name="column.size" value="100%"/>
<put name="label" value="RTF" />
</definition>
<definition name="control.property.additionalComments">
<put name="bundle.name" value="ControlCommentBundle"/>
<put name="property.name" value="Additional Comments"/>
<put name="display.type" value="rich.text.area"/>
<put name="label" value="Additional Comments:" />
</definition>
If you wish to change the display parameters of the HTML area - the height and width of the
input area - you must modify the following two lines of the definition:
in the Control details page.
Hiding an Existing Object Property Field

If you do not need to display certain property fields in the compliance object Details page, you
can hide the field by modifying the configTileDefinitions.xml file and commenting out the field
identifier from the list.
One item to take into consideration when deciding to hide a field is that some reports rely on
certain property fields presence to run. Hiding a field that a report relies on can cause the
report to fail or return unexpected results.
The fields currently references by the supplied reports are:
Compliance Object
Referenced Properties
Accounts
Assertions
Processes
Process Type
Transaction Type
Impact
IT Process
Financial Statement Close Process
Controls
Control Evaluation
Control Type
Who Performs Control
Document Location
Walkthroughs
IT Dependent
Tests
Date Performed
Performed By
Test Result
Effectiveness
Project Items
Due Date
Action Items
Assignee
Start Date
Percent Complete
Business Location
To hide a property field:

1.

2.

changes.
3.
4.
example, if you are modifying an account, the string would be account.prop.body.
Uncomment the definition for the compliance object and modify the <putlist> tag to
comment out the list entry for the property to be hidden, as in the example below:
<-- <add value="account.property.accountNumber"/> -->
</putList>
The above example would hide the Account Number field in the Account Detail page, as
well as from the Edit screen and from any reports run on accounts.
5.
Modifying Property Labels

Each property of a compliance object has a label associated with it. The label is the descriptive
text that appears to the left of the property field. You can change the text of the label by
modifying the definition of the property in the configTileDefinitions.xml file.
If you want to modify a property that is not located in the configTileDefinitions.xml file, you
must create a definition that extends the original property definition. Then, replace the property
in the property list of the object definition and add the extended definition to the
configTileDefinitions.xml file. The following procedures will explain both methods of replacing
the property label.
Modifying an Existing Property in configTileDefinitions.xml

If the property definition already exists in the configTileDefinitions.xml file, you do not need to
re-copy the definition.
To modify an existing property label:
1.
2.
3.

Find the property definition for the property whose label you want to modify.
Add the following line to the property definition:
<put name="label" value="New Text Here" />
The value of name must be label and the value of value is the new text that will
replace the existing label.
4.
Save your changes to configTileDefinitions.xml and restart the services.
Modifying an Non-Existent Property in configTileDefinitions.xml

To modify a label for a property whose definition does NOT reside in the
configTileDefinitions.xml file, follow the procedure below:
1.
2.

Find the object definition for the compliance object that has the property label you want
to change.
For example, say you want to change the label of the Assignee property on the Task
compliance object. The Assignee property is not defined in the
configTileDefinitions.xml file, so well have to extend the definition here and provide a
new label. Here is a sample Task object definition from configTileDefinitions.xml.
3.
4.
<definition name="task.prop.body">
<add value="task.property.assignee"/>
<add value="task.property.businessLocation"/>
<add value="task.property.startDate"/>
<add value="task.property.dueDate"/>
<add value="task.property.percentComplete"/>
<add value="task.property.predecessor"/>
</putList>
</definition>
Now, replace the assignee property with the entry for the extended definition.
<definition name="task.prop.body">
<add value="extended.task.property.assignee"/>
<add value="task.property.businessLocation"/>
...
Provide the property definition for the extended property. The syntax for the extended
property looks like this:
<definition name="extended.task.property.assignee"
extends="task.property.assignee">
<put name="label" value="Responsible Person"/>
</definition>
The value of extends is the original property the new extended property is
augmenting.
5.
Save your changes to the configTileDefinitions.xml file and restart the services.
Modifying the Overview Label

If the modified property appears in an Overview page, you will also have to modify the property
in the Overview listing definition.
Additional Modifications 108
Additional Modifications
Overview
This section details some of the other modifications you can make to the appearance and
functionality of SOX Express.
Topics in this section include:
Configuring the Compliance Object Tables on page 108

Configuring the Compliance Object Listings on page 111
Configuring the User Selector Tool on page 114
Redirecting the SOX Express Logout Link on page 116
Configuring the Compliance Object Tables

When you view the Details page for a compliance object, the page contains tables for the
parent compliance objects, and the associated (child) compliance objects. These tables have
different columns that display varying information about the specific compliance object types.
For example, the Associated Accounts and Parent Accounts tables show three columns of
information: Name, Description, and Assertions. It is possible to modify the tables to display
additional columns with other property fields, or change the existing columns to show new
information, or to simply remove a column entirely.
When you modify the columns for a particular compliance object type, the change will appear
everywhere the object type appears in a table. You cannot specify different columns for the
Parent Accounts table and the Associated Accounts table, for example.
Note: The parameters of the table itself cannot be modified. Therefore, any information you
add must share the same table width as the rest of the table. If you add three columns to the
table, the table will still take up the same horizontal width as the original three columns. This
can lead to awkward screen layout and some unusual table formatting. It is recommended that
you only display the most important information using the table columns.
Adding a Column to a Compliance Object Table

To add a column to a compliance object table:
1.

2.

changes.
3.
4.
by the string <object> List Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account List
Definitions.
add the list entry for the column to be added, as in the example below:
<putList name="table.field.list" >
<add value="account.item.list.field.name" />
<add value="icdocumentation.item.list.field.description" />
<add value="account.item.list.field.assertions" />

<add value="account.item.list.field.accountnumber" />
</putList>
The above example would add the Account Number field to the table in a new column.
The order of the values in the putList statement determines the order in which the
columns are displayed.
5.
Below the list definition for the compliance object type, create a new definition for the
field to be displayed in the new column. It should look like the following:
<definition name="account.item.list.field.accountnumber">
<put name="type" value="custom.property"/>
<put name="bundle" value="SOXAccount"/>
<put name="property" value="Account Number"/>
</definition>
where the value of name matches the new value you added to the putList; the value
for type is always custom.property; the value for bundle is the property bundle
where the custom property is contained; and the value for property is the exact name
of the custom property to be displayed.
6.
Replacing a Column in a Compliance Object Table

1.

2.

changes.
3.
4.
Definitions.
Uncomment the definition for the compliance object and comment out the line for the
property you wish to replace inside the <putlist> tag to add the list entry for the
column to be added, as in the example below:

</putList>
5.
Add a new line for the property you wish to add inside the <putlist> tag, as in the
example below:
</putList>
The above example would add the Account Number field to the table in place of the
Assertions column. The order of the values in the putList statement determines the
order in which the columns are displayed.
6.
</definition>
7.
Modifying the Label of a Compliance Object Table Column

If you have added a column to a compliance object table, and you wish to rename the column,
you can override the displayed text (by default, the property label) by specifying a new label
parameter in the property listing definition.
To change the displayed text in the column heading:
1.

2.

changes.
3.
4.
Definitions.
Below the listing definition, find the property definition for the column you want to
modify.
For example, a definition might look like this:
</definition>
Note: If you are changing the label of a default property (one originally supplied with
SOX Express), you will have to create a property definition for the default property.
5.
Add the following line to the definition:

<put name=label value=New Column Name/>
</definition>
where New Column Name is the new text to appear as the property name in the
column heading.
6.
Hiding a Column in a Compliance Object Table

1.

2.

changes.
3.
4.
Definitions.
comment out the list entry for the column to be hidden, as in the example below:
</putList>
The above example would hide the Assertions column from the table.
5.
Configuring the Compliance Object Listings

When you click on the Action menu link for a compliance object type, the displayed page
contains an expandable list of the various compliance objects. This table has different columns
that display information about the specific compliance objects.
For example, the Accounts listing displays three columns; Name, Description, and Assertions. It
is possible to modify the account listing table to display additional columns with other property
fields, or change the existing columns to show new information, or to simply remove a column
entirely.
Note: The parameters of the table itself cannot be modified. Therefore, any information you
add must share the same table width as the rest of the table. If you add three columns to the
table, the table will still take up the same horizontal width as the original three columns. This
can lead to awkward screen layout and some unusual table formatting. It is recommended that
you only display the most important information using the table columns.
Adding a Column to a Compliance Object Listing

To add a column to a compliance object listing:
1.

2.

changes.
3.
by the string <object> Tree Definitions where <object> is the object you want to
modify. For example, if you are modifying an account, the string would be Account Tree
Definitions.
Note: Business Entities, Issues, and Test Results do not use an expandable tree view,
and therefore do not have List Definitions.
4.
add the list entry for the column to be added, as in the example below:
<add value="account.item.list.field.assertions" />
</putList>
The order of the values in the putList statement determines the order in which the
columns are displayed.
5.
</definition>
6.
Replacing a Column in a Compliance Object Listing

To replace a column in a compliance object listing:
1.

2.

changes.
3.
4.
Definitions.
Uncomment the definition for the compliance object and comment out the line for the
property you wish to replace inside the <putlist> tag to add the list entry for the
column to be added, as in the example below:
</putList>
5.
Add a new line for the property you wish to add inside the <putlist> tag, as in the
example below:
</putList>
The above example would add the Account Number field to the table in place of the
Assertions column. The order of the values in the putList statement determines the
order in which the columns are displayed.
6.
</definition>
7.
Modifying the Label of a Compliance Object Listing Column

If you have added a column to a compliance object listing definition, and you wish to rename
the column, you can override the displayed text (by default, the property label) by specifying a
new label parameter in the property listing definition.
To change the displayed text in the column heading:
1.

2.

changes.
3.
4.
Definitions.
Below the listing definition, find the property definition for the column you want to
modify.
For example, a definition might look like this:
</definition>
Note: If you are changing the label of a core property, you will have to create a
property definition for the core property.
5.
Add the following line to the definition:

<put name=label value=New Column Name/>
</definition>
where New Column Name is the new text to appear as the property name in the
column heading.
6.
Hiding a Column in a Compliance Object Listing

To hide a column in a compliance object listing:
1.

2.

changes.
3.
4.
Definitions.
comment out the list entry for the column to be hidden, as in the example below:
</putList>
The above example would hide the Assertions column from the table.
5.
Configuring the User Selector Tool

Configuring the User Segment Size
SOX Express features a new user selector tool that breaks the list of users into 10-user
segments for quickness of browsing. The number of users in each segment is configurable via a
setting in the sosa.properties configuration file.
If you wish to increase the number of names in each segment, do the following:
1.
2.
3.
Open the sosa.properties file in a text editor. The file can be found in the
\bea\weblogic81\config\OpenpagesDomain\applications\sosa\conf directory.
Find the following line:
user.bucket.size=10
Change the value to the number of users desired. In order to have 25 users in each
segment, change the line to the following:
4.
user.bucket.size=25
Save your changes and restart the SOX Express services to view the change.
Specifying a Group for the User Selector

If you want to constrain the list of users that can be chosen as a value for a compliance object
property, you must replace the existing user selector with the original dropdown user selector.
To change the user selector to the original and specify a group for the list:
1.
2.
3.
4.
5.
Open the configTileDefinitions.xml file in a text editor. Make sure you back up the file
before making any changes.
Search for the string select.user.dropdown. An example definition is displayed.
Copy the example and paste it outside of the comment tags. The example looks like the
following:
<definition name="customer.entity.property.ExecutiveOwner">
<put name="bundle.name" value="SOXObjectOwners"/>
<put name="property.name" value="Executive Owner"/>
<put name="display.type" value="select.user.dropdown"/>
<put name="select.user.group" value="SOXUsers"/>
<put name="select.user.group.include.subgroups" value="yes"/>
</definition>
Replace the following strings with your property information:
customer.entity.property.ExecutiveOwner with the property definition name
of the field you are modifying.
SOXObjectOwners with the bundle that contains the custom property
Executive Owner with the label of your custom property.
SOXUsers with the group whose members will be listed in the user selector.
Save your changes when you have finished. You will have to restart the SOX Express
services to see the new behavior.
Configuring the Displayed Fields

Administrators can modify the fields that are displayed in the user selector and user group
selector by updating a definition in the configTileDefinitions.xml configuration file. The two
selectors share the same definition, and cannot be configured individually.
To modify the displayed fields:
1.
2.
3.
Open the configTileDefinitions.xml file in a text editor. Make sure you back up the file
before making any changes.
Search for the string config.user.selector.table.field.list. An example definition is
displayed.
Copy the example and paste it outside of the comment tags. The example looks like the
following:
<definition name="config.user.selector.table.field.list">
<putList name="table.field.list">
<add value="email" />
<add value="firstName" />
<add value="lastName" />
<add value="description" />
</putList>
</definition>
4.
5.
6.
The example contains all of the potential fields that can be displayed in SOX Express.
To hide any of these fields, comment out the appropriate line with the  tags.
For example, to hide the e-mail address of users, modify the example as follows:
<definition name="config.user.selector.table.field.list">
<putList name="table.field.list">

<add value="firstName" />
<add value="lastName" />
<add value="description" />
</putList>
</definition>
To re-order the list, re-arrange the listings from top to bottom - each entry corresponds
to a left-right orientation. For example, to display the last name before the first name,
move the lastName line above the firstName line.
Save your changes when you have finished. You will have to restart the SOX Express
services to see the new behavior.
Redirecting the SOX Express Logout Link

By default, clicking the Logout link in the header pane logs the user out and displays the login
page. This destination page can be changed by modifying a property in the aurora.properties
file.
You can find the aurora.properties file in the \<weblogic-installdir>\weblogic81\aurora\conf
directory.
To redirect the logout link:
1.
2.
3.
Open the aurora.properties file in a text editor.

Search for the string logout.link.url.
Enter a fully qualified URL as the value of the logout link.
Example:
4.
5.
logout.link.url=http://www.openpages.com
Save your changes and exit the text editor.
Restart the OpenPages and SOX servers.
Displaying the Sub-Processes Header in the Action Menu

SOX Express displays a list of compliance object types as headings on the Action Menu. In SOX
Express 3.0.4, the sub-process compliance object was added, and the heading included in the
Action Menu.
Since not all organizations use sub-processes in their compliance object hierarchy, we have
included a flag in the sosa.properties file called subprocesses.show.menu.item. By default,
this flag is set to true. If you do not use sub-processes and wish to remove the Sub-Processes
heading from the Action Menu, set this flag to false and restart the SOX Express services.
Resolving Duplicate Names During Copy Operations

There is an optional setting in the sosa.properties configuration file that can control the
behavior of SOX Express when it encounters duplicate compliance object names during a copy
operation. By default, the copy operation will create a new version of the destination object
containing the information of the copied object.
The sosa.properties file contains the setting expose.copy.options, which is set to false by
default. When set to true, additional options are displayed during the copy process which the
user can use to set how duplicate names will be handled for the current copy.
Setting the Default Copy Behavior

In addition, you can set the default copy behavior of SOX Express (whether the Advanced Copy
Options are displayed or not) by modifying the setting copy.options.default in the
sosa.properties file to one of the following values (without the quotation marks): overwrite
(the existing default), copyof, or existing.
You will need to restart the SOX Express services after making either change in order to pick up
the new settings.
Copy Behavior Options

The new options are:
Create a new version of the existing object in the destination directory

A new version of the object in the target directory is created with all of the information
of the copied object. All prior version of the object in the target directory are
maintained. Corresponds to the overwrite value of the copy.options.default setting.
Create new objects whose names are prefixed with Copy Of

When the copy occurs, any objects with the same name as an existing object in the
target location will be renamed to Copy of <objectname>. Corresponds to the
copyof value of the copy.options.default setting.
Do not overwrite existing objects

If a copied object has the same name as an object in the target location, that file will
not be copied. All other objects (without duplicate names) will still be copied to the
target location. Corresponds to the existing value of the copy.options.default setting.
Note: If you choose this option, you should examine the results of copy operations to
determine whether any associations between objects have changed as a result of the
copy. For example, if an associated risk is not copied to the new location because an
existing risk has the same name, the copied parent process of the risk will be
associated with the pre-existing risk in the target location.
Using an SSL Connection

To access SOX Express using an SSL connection, you should use the following URL (assuming
the default settings were kept during the installation):
https://<SOXSERVER>:7010/sox
where <SOXSERVER> is the fully qualified hostname of your server machine.
For example:
https://www.openpages.com:7010/sox
You must have an SSL digital certificate in order to use SSL with SOX Express. Instructions on
configuring an SSL certificate with the BEA WebLogic server can be found at:
http://e-docs.bea.com/wls/docs81/secmanage/ssl.html
Using Netegrity SiteMinder 119
Using Netegrity SiteMinder

Overview of SiteMinder Integration
SOX Express integrates with the Netegrity SiteMinder website security application to provide
secure, managable access to your SOX Express application. The following sections detail how to
configure your SOX Express installation to interact with SiteMinder.
Installing and Configuring SiteMinder

Configuring SOX Express for SiteMinder Integration
Installing and Configuring SiteMinder

This document assumes that you have already installed a SiteMinder Policy Server for your
existing web server. You will need to install the following additional SiteMinder components to
integrate with SOX Express:
the SiteMinder Web Agent (for WebLogic)

the SiteMinder Servlet Agent (for WebLogic)
The agents must pass the SOX Express user name in the response header attributes.
Configuring SOX Express for SiteMinder Integration

To configure SOX Express to work with the SiteMinder application:
1.
2.
3.
Edit the aurora.properties file, located in the \<weblogic-installdir>\

weblogic81\aurora\conf directory.
Add the following line:
security.siteminder.enabled=true
Modify the following line:
sox.app.security.auth.siteminder.enabled=false
to
4.
sox.app.security.auth.siteminder.enabled=true
Save the changes to aurora.properties and restart the SOX Express server.
Note: For instructions on restarting SOX Express and OpenPages, see the SOX Express
Installation Manual included with your installation media.
Configuring OpenPages for SiteMinder Integration

To configure OpenPages to work with the SiteMinder application:
1.
2.
3.
Edit the aurora.properties file, located in the \<weblogic-installdir>\

weblogic81\aurora\conf directory.
Add the following line:
security.siteminder.enabled=true
Modify the following line:
op.app.security.auth.siteminder.enabled=false
to
4.
op.app.security.auth.siteminder.enabled=true
Save the changes to aurora.properties and restart the OpenPages server.
Sarbanes-Oxley Express and Netegrity SiteMinder should now be configured correctly.
The Notification
Manager
Overview of the Notification Manager

The Notification Manager is an add-on tool for Sarbanes-Oxley Express
(versions 3.0.1 and later) that automatically creates action items and
notification e-mails when the certain criteria are met.
The Notification Manager allows users to define a set of object
properties and values that will trigger the creation of an action item and
the sending of a notification e-mail. The user responsible for the item
will receive the e-mail and see the action item in their Home page,
alerting the user to their necessary tasks.
For example, a notification event can be set to run nightly that will send
a notification e-mail to all users who have Tests that do not have
completed Test Results associated with them.
Why would I use Notifications?

Notifications allow you to alert people that important dates are
approaching, and remind them that they still have outstanding tasks to
perform before the date arrives. Since notification can be tied to the
value of a compliance object property, you can target the reminder to
only those people who meet the criteria for the notification.
For example, you can set up a notification to remind all Control owners
who have controls that have a value of Undetermined for the Control
Evaluation field, and set the notification to start 20 days after the
beginning of the quarter.
About the Notification Manager 121
About the Notification Manager

Exploring the Notification Reports
When the Notification Manager is installed, a new folder in OpenPages is created under the
Publishing/Reporting/SOX directory named Notifications. This folder contains the reports and
report templates required to set up a notification event. The contents of the folder are:
the Test Notifications page (report). This is a prepared report that will send e-mail to
all Test Performers that have Tests that have not been performed and are due within
the next 15 days.
the Undetermined Controls page (report). This is a prepared report that notifies users
who have Controls assigned to them that are marked as Undetermined.
the Test Notification Template. This report template is used when creating your own
reports to notify Test Performers and Reviewers about incomplete Test Results.
the General SOX Notifications Template. This template is used to create your own
notification reports using your own custom trigger conditions. Detailed information
about creating your own notification reports can be found in Using the General SOX
Notifications Template on page 122 of this guide.
This guide will explain how to set up and run notification reports based on the included Test
Notification Template and the General SOX Notifications Template.
Using the Notification Manager

In order to set up and execute a notiification, the following general steps will need to be
performed. Each step will be explained in detail in later sections.
Step One: Preparing Your Data on page 122

Step Two: Creating the Notification on page 123
Step Three: Triggering the Notification on page 129
Once the steps are completed, you will have a notification that can be run manually or
scheduled to be run automatically, depending on your choices.
Requirements for Setting Up a Notification

In order to set up a notification event, you must have the following:
A user account with Publishing access to the OpenPages Server

Administrator access to the OpenPages server machine (for scheduling reports to run
automatically)
Results of Running a Notification Report

When a notification report is run, the following events occur (based on the setting you chose
during the notification creation process):
When the report is run, a milestone is generated with a name based on the report and
the Milestone Suffix parameter.
For each compliance object that generates a notification, an action item is created
under the report milestone. This action item is assigned to the Executive or Primary
Owner of the compliance object.
A notification e-mail is generated for the Executive or Primary Owners detailing the
compliance objects that require attention.
Step One: Preparing Your Data 122
Step One: Preparing Your Data

Overview
The first step in setting up a notification is to make sure that your compliance objects have the
necessary information that will be required by the notification report. If the compliance objects
are not up-to-date, the report will not find the data it needs and will either return a sub-set of
the entire results, or fail to run at all.
For example, when running the Undetermined Controls report, the report checks the Control
Evaluation field for a value of Undetermined. If your controls do not begin with a status of
Undetermined, the report will not be able to differentiate between legacy settings, and
controls that have not been evaluated yet.
Using the Test Notification Template

If you plan to use notifications based on the Test Notification Template, or the provided Test
Notifications report, you will need to make sure that your Tests have the following properties
populated correctly:
Test Reviewer (the person responsible for verifying that the tests are completed)
Test Performer (the person responsible for executing the tests)
Frequency (whether the test is performed Annually, Quarterly, or Monthly)
Relative Due Date (when the test should be completed, measured in days after the
beginning of the Frequency period)
Note: If you are viewing existing Tests that were created before version 3.0.1, the new
properties will not be visible on the Details page of the Test. To display the new properties on
an existing Test, click the Edit button. The new properties will be included on the Edit page.
When you Save your changes, the new properties and values will now be displayed on the
Details page. You will need to enter values for each pre-existing Test in order to use the
Notification Manager.
Using the General SOX Notifications Template

If you are creating notifications based on property values, make sure that the properties you
are checking have valid values.
If you are creating custom properties and plan to run notifications based on those properties,
make sure that you update all of the necessary compliance objects with the new custom
property field(s).
Note: The General SOX Notifications template cannot compare date fields using the greater
than/less than/equal/not equal operators.
Step Two: Creating the Notification 123
Step Two: Creating the Notification

Overview
SOX Express comes with two templates for creating notification reports - Test Notifications and
General SOX Notifications.
Reports created with the Test Notification template are targeted at Tests and are used to notify
Test Performers and Reviewers that incomplete Tests exist. It also contains special logic to deal
with setting relative due dates and gathering information from both Tests and Test Results.
The General SOX Notifications template allows users to set up to three properties and property
values to evaluate. You can only evaluate properties for a single compliance object type.
The following sections explain the various settings available to each type of notification report.
Creating a Test Notification

To create a new Test Notification:
1.
2.
3.
Log in to OpenPages as a user with Publishing privileges. The Home page is displayed.
Click the Browse Channels link on the Action menu. A list of channels is displayed.
Navigate to the Reporting/SOX/Notifications folder. The contents of the folder are
displayed.
4. Click the Add Page... button at the top of the folder list. The Describe Page screen is
displayed.
5. Enter a name and description for the notification report and choose the Test Notification
Template as the page template. Click Next to continue.
6. Enter the information for your notification. When you are finished, click Apply to save
your changes.
Note: Detailed information about the various fields can be found following this
procedure.
7.
Click Finish to save the new report.
Understanding the Test Notification Fields

The following table contains an explanation of the various fields available to notification reports
based on the Test Notification Template:
Parameter
Milestone Suffix
Explanation
String appended to the milestone created as a result of
running the report. When the report is run, a milestone is
created to hold the action items that will be created as a
result of the notification process. By default, the milestone is
named for the content type that the report targets (in this
case - Tests). The milestone suffix is added to the end of the
milestone name to create a unique name for holding the
results of the notification report.
The name is appended with a dash, so a Milestone Suffix of
Weekly Reminder will result in a milestone named Tests Weekly Reminder.
Sender Name
This is the name that will appear as the sender of the

notification e-mail.
Sender Address
The e-mail address that appears as the sender e-mail

address on the notification e-mail.
Parameter
Explanation
Subject
The subject of the notification e-mail.
Select a Test Frequency
(Annually, Quarterly, Monthly)

Selecting a Test Frequency limits the notification report to
only send out notifications for incomplete Tests that match
the chosen frequency.
Notify Test Reviewer ___

days before due date
The number of days before the test due date that the
notification e-mail will be sent to the user listed as the Test
Reviewer.
The Due Date for a Test is set in the Relative Due Date field
on the Test compliance object. The Relative Due Date is the
number of days after the beginning of the test period (as set
in Frequency - Annually, Quarterly, Monthly).
For example, a Relative Due Date of 60 and a Frequency of
Quarterly means that the Test must be completed 60 days
after the beginning of the most recent quarter. If you set
this field (Notify Test Reviewer...) to 14, then 14 days before
the Relative Due Date the notification will alert the Test
Reviewer.
Note: SOX Express considers financial quarters to begin on
January 1st, April 1st, July 1st, and October 1st. If your
financial quarter begins on a different date, you may want to
adjust the Relative Due Date.
Notify Test Performer ___

days before due date
The number of days before the test due date that the
notification e-mail will be sent to the user listed as the Test
Performer.
The Due Date for a Test is set in the Relative Due Date field
on the Test compliance object. The Relative Due Date is the
number of days after the beginning of the test period (as set
in Frequency - Annually, Quarterly, Monthly).
For example, a Relative Due Date of 60 and a Frequency of
Quarterly means that the Test must be completed 60 days
after the beginning of the most recent quarter. If you set
this field (Notify Test Peformer...) to 21, then 21 days before
the Relative Due Date the notification will alert the Test
Performer.
Note: SOX Express considers financial quarters to begin on
January 1st, April 1st, July 1st, and October 1st. If your
financial quarter begins on a different date, you may want to
adjust the Relative Due Date to take this into account.
Also examine past ___ days

when evaluating
completeness
The number of previous days to check when looking for

incomplete Tests.
By default, the notification report only checks for the exact
value of the Notify Test Reviewer/Performer X days before
due date fields, so if the report is not run for a few days,
some incomplete Tests with due dates that do not exactly
match the values may not create notifications.
This setting provides some overlap in case the report is not
run every day. If an Action Item already exists for the Test,
a new one will not be created.
Send repeat notifications
If this field is set to true, an e-mail will be sent to the Test

Reviewer/Performer every time the notification report is run
and the Test continues to be incomplete. If set to false,
the Performer/Reviewer will receive a single e-mail the first
time the incomplete Test is included in the report results.
Parameter
Explanation
General Message
This text will appear as the introductory text in the body of

the e-mail for both Test Perfomers and Test Reviewers.
Send mail to Test Reviewers
If set to true, an e-mail message will be generated that

contains the incomplete tests belonging to the Test
Reviewer.
Message to Test Reviewers
This text will appear underneath the General Message on emails to Test Reviewers.
Send mail to Test Performers
If set to true, an e-mail message will be generated that

contains the incomplete tests belonging to the Test
Performer.
Message to Test Performers
This text will appear underneath the General Message on emails to Test Performers.
Group notifications by
This setting is used to group the tests that meet the criteria
for notification within the notification e-mail.
Test Reviewer property
Defines the property that contains the Test Reviewer user.

Should only be modified if you are using a custom property.
Test Performer property
Defines the property that contains the Test Performer user.

Test Due Date property
Defines the property that contains the Test Due Date.

Test Frequency property
Defines the property that contains the Test frequency.

Test Result Date Performed

property
Defines the property that contains the date the Test Results
were performed. Should only be modified if you are using a
custom property.
Mail Server
The machine address that contains the mail server. If the

server machine contains a mail server, the setting should be
localhost.
SOX Server
The full URL of the SOX Express server machine. This

address is used to create the links contained in the
notification e-mail, and should NOT be set to localhost.
Report Title
The text displayed as the title of the notification report.
Scope
The scope parameter is used to limit the range of the

notification report. If you do not want to limit the scope of
the notification report, leave it set to _op_sox/Project/
Default.
If you wish to change the scope, click the Browse button
and select the business entity hierarchy you want to include
in the notification report. Only the compliance objects under
that business entity will be evaluated when the report is run.
Library Filter
When you are running a notification report, you do not

usually want to include the Master Library in the report
results, since they are not considered active.
If the path contains the value of the Library Filter
parameter, it will not be included in the report results.
Project
Internal parameter. Do not modify.
Reporting Period
Creating a General Notification

The following table contains an explanation of the various fields available to reports based on
the General SOX Notifications Template:
Parameter
Milestone Suffix
Explanation
String appended to the milestone created as a result of
running the report. When the report is run, a milestone is
created to hold the action items that will be created as a
result of the notification process. By default, the milestone is
named for the content type that the report targets (in this
case - Tests). The milestone suffix is added to the end of the
milestone name to create a unique name for holding the
results of the notification report.
The name is appended with a dash, so a Milestone Suffix of
Weekly Reminder will result in a milestone named Tests Weekly Reminder.
Sender Name
This is the name that will appear as the sender of the

notification e-mail.
Sender Email
The e-mail address that appears as the sender e-mail

address on the notification e-mail.
Email Subject
The subject of the notification e-mail.
General Message
This text will appear as the introductory text in the body of

the e-mail for both Executive Owners and Primary Owners.
Note: If you are entering a plain-text message, any escaped
characters (such as newlines, etc.) must be preceded with
two backslashes instead of one (e.g. \\n). If you are using
HTML for your e-mail message, this is not necessary.
Send mail to Executive

Owners
If set to true, an e-mail message will be generated and

sent to the Executive Owner of the compliance object that
generated the notification.
If no Executive Owner is set on the compliance object, the
Notification Manager will look up the hierarchy until a valid
Executive Owner is found.
If no Executive Owner is found, no notification will be
generated.
Message to Executive
Owners
This text will appear underneath the General Message on emails to Executive Owners.
Send mail to Primary Owners
If set to true, an e-mail message will be generated and

sent to the Primary Owner of the compliance object that
generated the notification.
If no Primary Owner is set on the compliance object, the
Notification Manager will look up the hierarchy until a valid
Primary Owner is found.
If no Primary Owner is found, no notification will be
generated.
Parameter
Message to Primary Owners
Explanation
This text will appear underneath the General Message on emails to Primary Owners.
Send repeat notifications:
If this field is set to true, an e-mail will be sent to the

Executive and/or Primary owners every time the report is
run and the compliance object continues to meet the
notification criteria. If set to false, the Executive and/or
Primary owners will receive a single e-mail the first time the
compliance object is included in the report results.
Note: If Create Action Items is set to false, then
notification e-mails will be sent each time the report is run,
regardless of the value of Send repeat notifications.
Content type to send

notifications for
Determines which compliance objects will be evaluated

when the report is run.
Notification reports can only be run against a single
compliance object type. If you want to run the same report
against multiple compliance object types, you will have to
create multiple reports, or provide different parameter
values in the command line.
[Filter Property 1
Filter Evaluation 1
Filter Value 1]
The report template contains three sets of Property/Value

evaluations that can be performed when determining which
compliance objects will generate a notification.
For example, if the three parameters have the following
values:
Filter Property 1: SOXControl.Control Evaluation
Filter Evaluation 1: =
Filter Value 1: Undetermined
then a notification would be generated if any Control had a
value of Undetermined for the Control Evaluation property.
Filter Property X
Contains the property to be considered when evaluating

whether a notification should be generated.
Filter Evaluation X
The evaluation method to be used when comparing the

compliance object property value with the Filter Value
Note: The possible operators are =,<> (not equals), <, >,
<=, and >=. Only the = operator can be used with strings.
All other operators only work with integers.
Filter Value X
Contains the value of the property to be considered when

generating notifications.
Create notification if
Determines whether all property/value evaluations need to

be true in order to create a notification, or if only one of
them needs to be true.
Group Notifications by
This setting is used to group the compliance objects that

meet the criteria for notification within the notification email.
Parameter
Create Action Items
Explanation
Determines whether an action item will be created for each
notification e-mail sent to an Executive or Primary Owner.
If an Action Item has already been created for the
compliance object, no new action item will be generated
Note: If this option is set to false, then notifications will
always be sent when the notification report is run,
regardless of the Send repeat notifications setting.
Action Item Description
An optional description for the created Action Items.
Action Item should be

completed in
If set, the Action Items Due Date will be set to the number
of days after the creation of the action item.
For example, a value of 14 would give the created Action
Item a due date two weeks after the creation of the Action
Item.
Mail Server
The machine address that contains the mail server. If the

server machine contains a mail server, the setting should be
localhost.
SOX Server
The full URL of the SOX Express server machine. This

address is used to create the links contained in the
notification e-mail, and should NOT be set to localhost.
Report Title
The text displayed as the title of the notification report.
Executive Owner Property
The property containing the Executive Owner value. Should

not be changed unless you are using a custom Owner field.
Primary Owner Property
The property containing the Primary Owner value. Should

not be changed unless you are using a custom Owner field.
Library Filter
When you are running a notification report, you do not

usually want to include the Master Library in the report
results, since they are not considered active.
If the path contains the value of the Library Filter
parameter, it will not be included in the report results.
Scope
The scope parameter is used to limit the range of the

notification report. If you do not want to limit the scope of
the notification report, leave it set to _op_sox/Project/
Default.
If you wish to change the scope, click the Browse button
and select the business entity hierarchy you want to include
in the notification report. Only the compliance objects under
that business entity will be evaluated when the report is run.
Project
Reporting Period
Step Three: Triggering the Notification 129
Step Three: Triggering the Notification

Overview
There are two ways to run the notification reports - manually and automatically. You can run
notification reports from the Reporting interface like any other report, or use the provided
command line interface to run the notification reports from outside Sarbanes-Oxley Express.
You can also schedule the notification reports to execute automatically by using the Windows
Scheduler tools to initiate the command line at a specific time.
The following sections will explain how to run your notification reports both manually and
automatically.
Running Notification Reports Manually

Running a notification report by hand works the same as running any other report through the
SOX user interface.
You can also run reports manually by entering a valid command line at a command prompt, as
detailed in the Running Notification Reports Automatically section.
Note: You cannot use the Preview functionality in the OpenPages user interface with
Notification reports.
To run a notification report:
1.
2.
3.
4.
Log in to SOX Express and click the Reports link on the Action menu.
Click on the Notificiations link to display the notification reports.
Choose the notification report you wish to run and click the name of the report.
A new window opens, and the results of the report are displayed.
Note: The report may take a short while to display - this is normal.
Running Notification Reports Automatically

Notification reports can be run automatically by scheduling the NotificationManager command
file to be executed at a certain time using the Windows Scheduler tool. You can run a single
report, an entire folder of reports, and run a single report against multiple datasets by
providing parameters to the report directly through the command line.
The Notification Manager Command Line Interface

The NotificationManager.cmd program can be found in the <WL_HOME>\aurora\util
\NotificationManager directory.
The following section details the allowable parameters that can be used with the
NotificationManager command.
Syntax
NotificationManager -Username=<username> -Password=<password>
-NotificationProgram=<full-path-to-notification-report>|-ProgramFolder=<path-to-foldercontaining-notification-reports> [-SaveOutput=<true|false>] [-LogSession=<true|false>]
-[{parameterName=parameterValue}] [-ParameterFile=<full-path-to-file>]
Parameters
All parameters are in the syntax -parameter=value. If the value of any parameter contains
spaces, that value must be contained within quotation marks.
Parameter Name
Explanation
-Username
The name of a valid SOX Express user with permission to

run the notification reports.
-Password
The password for the user name set in -Username.
-NotificationProgram
(Required unless -ProgramFolder is specified) The full path

to the notification report the command will run, starting
with the Reporting channel. Should not begin with a leading
slash.
Example: -NotificationProgram=Reporting\SOX\
Notifications\Test Notifications Report
-ProgramFolder
(Required unless -NotificationProgram is specified)

Specifies a folder containing notification reports. All reports
in that folder will be executed when the command is run.
Example: -ProgramFolder=Reporting\SOX\Notifications
-SaveOutput
(Optional) Can be true or false. If set to true, the output

of the report will be saved to an output file in the /
output_files directory under the
aurora\utils\NotificationManager directory. If the
parameter is not present, no output file will be created.
The file name is the name of the notification report (or
folder) with an html extension. If an output file with that
name already exists, a timestamp extension will be added
to the end of the existing files name and the older file will
be moved to the output_files\archive folder.
Example: Undetermined Controls.html.200406060103
-LogSession
(Optional) Can be set to true. If set, the activities of the

NotificationManager will be written to a log file. The log file
will be located in the logs directory under the
\aurora\util\NotificationManager directory.
The name of the log file is NotificationManager.log. The
file has a maximum size of 1MB, and will be rotated into
the \logs\archives directory when the limit is exceeded.
-parameter=value
If you wish to pass a value for a notification report

parameter, you may include the parameter and value
directly in the command line. The parameter name must
match the report parameter name exactly.
The parameter names can be viewed by logging into
OpenPages and navigating to the channel folder containing
the report page. The parameter names are shown in the
Details page for the report, which can be viewed by clicking
on the name of the report in the channel folder view.
Examples: -mailServer=mail.openpages.com
-generalMessage=Please do not ignore this e-mail.
Parameter Name
-ParameterFile
Explanation
Specifies a text file containing a list of parameter=value
pairs (equivalent to entering individual -parameter=value
entries into the command line directly). Each
parameter=value pair should be on a single line.
Value is the full path to the file, including the file name.
Example: ParameterFile=c:\bea\weblogic81\aurora\util\Notification
Manager\notification_parameters.txt
Scheduling Your Automatic Notification

Because the Notification Manager can be run from a simple command prompt, you can easily
schedule the Notification Manager to be executed at any time with the standard Windows
Scheduler.
To set up a scheduled event for the Notification Manager:
1.
2.
3.
4.
From the Windows menu on the application server machine, select Settings | Control
Panel.
Open the Scheduled Tasks item in the Control Panel.
Double-click the Add Scheduled Task item.
On the Task tab, fill in the Run field with the path to the NotificationManager program
and any parameters you require to run the report.
Example: To run a single report, the contents of the Run field might look like the
following:
c:\bea\weblogic81\aurora\util\NotificationManager
NotificationManager.cmd -Username=SOXAdministrator
-Password=SOXAdministrator -NotificationProgram=Reporting/SOX/
Notifications/Test Notifications
5.
6.
7.
8.
9.
10.
11.
Edit the Start in field to be the path to the NotificationManager program, i.e.
c:\bea\weblogic81\aurora\util\NotificationManager.
Make sure the Run as: is set to the current Windows user.
Check the checkbox next to Enabled to set a time for the command to be executed.
Click the Schedule tab to display the Schedule settings.
Set the days and time you want the notification report(s) to run.
Click Apply and then Ok to save your changes and exit the scheduler.
Repeat these steps for each report you wish to run. Remember that you can use the
-ProgramFolder parameter to run all the reports in a specified folder at the same time.
The SOX Express

Reporting Schema
Overview
The following appendix describes the tables that are part of the SOX
Express reporting schema. The reporting schema is used to make SOX
Express data available to optional or third-party reporting tools.
Note: The table structures documented here correspond to the default
Standard SOX Schema supplied with SOX Express. For customized
schema, the table structures would be different.
133
Compliance Object Tables

Business Entity
Physical Name: SX_ENTITY
Description: This table contains the information relating to the Business Entity compliance
object.
Primary Key: ENTITY_ID
Indices: 11
Column Name
Description
Native Type
ENTITY_ID
The unique ID of the Business

Entity
NUMBER(38,0)
EN_CREATIONDATE
Date the entity was created
DATE
EN_CREATOR
The resource ID of the user who

created the Business Entity
NUMBER(38,0)
EN_DESCRIPTION
The user-created description of the

compliance object
VARCHAR2(2048)
EN_ENTITY_IN_SCOPE
May be used to include or exclude

the business entity from
downstream compliance-related
activities such as testing,
attestation, and reporting.
VARCHAR2(256)
EN_ENTITY_TYPE
May be used to categorize the

entitys level in the organization
(sales office, regional
headquarters, etc.)
VARCHAR2(256)
EN_ERP_COMPANY_CODE
May be used to identify the

business entity using the code used
in an ERP system.
VARCHAR2(256)
EN_EXECUTIVE_DELEGATE
May be used to assign the secondhighest level of responsibility for

the business entity
VARCHAR2(4000)
EN_EXECUTIVE_OWNER
May be used to assign the highest

level of responsibility for the
business entity
VARCHAR2(4000)
EN_EXPORTLABEL
Label assigned to the level of the

entity hierarchy
VARCHAR2(4000)
EN_FULLPATH
The folder path of the compliance

object.
VARCHAR2(1024)
EN_LOCKSTATUS
Denotes whether the object can be

modified
VARCHAR2(256)
EN_MODIFIEDDATE
The last date the object was

modified
DATE
EN_NAME
The user-defined name of the

object.
VARCHAR2(4000)
EN_NESTINGLEVEL
Level of the business entity within

the business entity hierarchy.
NUMBER
EN_NESTINGPATH
Concatenated list of the ancestor

business entities, if any.
VARCHAR2(4000)
134
Column Name
Description
Native Type
EN_PARENTFOLDERID
The unique identifier of the parent

folder of the business entity.
NUMBER(38,0)
EN_SOXURL
The constructed URL of the

business entitys details page.
VARCHAR2(4000)
EN_VERSIONID
The number of the current version

of the business entity.
NUMBER(38,0)
CORPORATE
Name of the top level business

entity, if any.
VARCHAR2(256)
DEPARTMENT
Name of the second level business

entity, if any.
VARCHAR2(256)
DIVISION
Name of the third level business

entity, if any.
VARCHAR2(256)
WORKGROUP
Name of the fourth level business

entity, if any.
VARCHAR2(256)
REPORTING _PERIOD
The user specified label of the

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_ENTITY (I1)
EN_CREATOR
IX2_SX_ENTITY (I2)
EN_ENTITY_IN_SCOPE
IX3_SX_ENTITY (I3)
EN_ENTITY_TYPE
IX4_SX_ENTITY (I4)
EN_ERP_COMPANY_CODE
IX5_SX_ENTITY (I5)
EN_EXPORTLABEL
IX6_SX_ENTITY (I6)
EN_FULLPATH
IX7_SX_ENTITY (I7)
EN_LOCKSTATUS
IX8_SX_ENTITY (I8)
EN_NAME
IX9_SX_ENTITY (I9)
EN_NESTINGLEVEL
IX10_SX_ENTITY (I10)
EN_NESTINGPATH
IX11_SX_ENTITY (I11)
EN_PARENTFOLDERID
135
Accounts
Physical Name: SX_ACCOUNT
Description: This table contains the information relating to Account compliance objects.
Primary Key: ACCOUNT_ID
Indices: 7
Column Name
Description
Native Type
ACCOUNT_ID
The unique ID of the compliance

object.
NUMBER(38,0)
AC_ACCOUNT_TYPE

account, at the highest level, into
various financial statements.
VARCHAR2(256)
AC_ANNUALIZED_VALUE
May be used to capture the account

balance from operational systems.
NUMBER(38,0)
AC_ASSERTIONS
May be used to indicate the

financial statement assertions that
must be made on the account.
VARCHAR2(256)
AC_CLASSIFICATION
May be used to sub-categorize the

account into various financial
statement account categories.
VARCHAR2(256)
AC_CREATIONDATE
Date the account was created
DATE
AC_CREATOR

created the compliance object.
NUMBER(38,0)
AC_DESCRIPTION

compliance object
VARCHAR2(2048)
AC_FULLPATH

object.
VARCHAR2(1024)
AC_LOCKSTATUS

modified
VARCHAR2(256)
AC_MODIFIEDDATE

modified
DATE
AC_NAME

object.
VARCHAR2(4000)
AC_PARENTFOLDERID

NUMBER(38,0)
AC_SOXURL

compliance objects details page.
VARCHAR2(4000)
AC_VALUE_AS_OF_DATE
May be used to capture the date on

which the Annualized Value data
was set or recorded.
DATE
AC_VERSIONID

of the compliance object.
NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
136
Table of Indices
Index Name
Table Column
IX1_SX_ACCOUNT (I1)
AC_ACCOUNT_TYPE
IX2_SX_ACCOUNT (I2)
AC_CLASSIFICATION
IX3_SX_ACCOUNT (I3)
AC_CREATOR
IX4_SX_ACCOUNT (I4)
AC_FULLPATH
IX5_SX_ACCOUNT (I5)
AC_LOCKSTATUS
IX6_SX_ACCOUNT (I6)
AC_NAME
IX7_SX_ACCOUNT (I7)
AC_PARENTFOLDERID
Account Assertions
Physical Name: SX_ACCOUNT_ASSERTIONS
Foreign Key: ACCOUNT_ID
Foreign Key Reference: SX_ACCOUNT.ACCOUNT_ID
Indices: 2
Column Name
Description
Native Type
ACCOUNT_ID
The unique ID of the object.
NUMBER(38,0)
AC_ASSERTIONS

financial statement assertions
that must be made on the
account.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_ACCOUNT_ASSERTIONS
(I1)
ACCOUNT_ID
IX2_SX_ACCOUNT_ASSERTIONS
(I2)
AC_ASSERTIONS
137
Sub-Accounts
Physical Name: SX_SUBACCOUNT
Description: This table contains the information relating to sub-account compliance objects.
Primary Key: SUBACCOUNT_ID
Indices: 10
Column Name
Description
Native Type
SUBACCOUNT_ID

object.
NUMBER(38,0)
AC_ACCOUNT_TYPE

account, at the highest level, into
various financial statements.
VARCHAR2(256)
AC_ANNUALIZED_VALUE
May be used to capture the account

balance from operational systems.
NUMBER(38,0)
AC_ASSERTIONS

financial statement assertions that
must be made on the account.
VARCHAR2(256)
AC_CLASSIFICATION
May be used to sub-categorize the

account into various financial
statement account categories.
VARCHAR2(256)
AC_CREATIONDATE
DATE
AC_CREATOR

NUMBER(38,0)
AC_DESCRIPTION

compliance object
VARCHAR2(2048)
AC_EXPORTLABEL
Descriptive label assigned to the

level of the account hierarchy
VARCHAR2(256)
AC_FULLPATH

object.
VARCHAR2(1024)
AC_LOCKSTATUS

modified
VARCHAR2(256)
AC_MODIFIEDDATE

modified
DATE
AC_NAME

object.
VARCHAR2(4000)
AC_NESTINGLEVEL
Level of the sub-account in the

account hierarchy.
NUMBER
AC_NESTINGPATH

accounts, if any.
VARCHAR2(4000)
AC_PARENTFOLDERID

NUMBER(38,0)
AC_SOXURL

VARCHAR2(4000)
AC_VALUE_AS_OF_DATE
May be used to capture the date on

which the Annualized Value data
was set or recorded.
DATE
138
Column Name
Description
Native Type
AC_VERSIONID

NUMBER(38,0)
GL_ACCOUNT
The top-level parent sub-account.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_ACCOUNT (I1)
AC_ACCOUNT_TYPE
IX2_SX_ACCOUNT (I2)
AC_CLASSIFICATION
IX3_SX_ACCOUNT (I3)
AC_CREATOR
IX4_SX_ACCOUNT (I4)
AC_EXPORTLABEL
IX5_SX_ACCOUNT (I5)
AC_FULLPATH
IX6_SX_ACCOUNT (I6)
AC_LOCKSTATUS
IX7_SX_ACCOUNT (I7)
AC_NAME
IX8_SX_ACCOUNT (I8)
AC_NESTINGLEVEL
IX9_SX_ACCOUNT (I9)
AC_NESTINGPATH
IX10_SX_ACCOUNT (I10)
AC_PARENTFOLDERID
Sub-account Assertions
Physical Name: SX_SUBACCOUNT_ASSERTIONS
Foreign Key: SUBACCOUNT_ID
Foreign Key Reference: SX_SUBACCOUNT.SUBACCOUNT_ID
Indices: 2
Column Name
Description
Native Type
SUBACCOUNT_ID
NUMBER(38,0)
AC_ASSERTIONS

that must be made on the subaccount.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
139
Table of Indices
Index Name
Table Column
IX1_SX_SUBACCOUNT_
ASSERTIONS (I1)
SUBACCOUNT_ID
IX2_SX_SUBACCOUNT_
ASSERTIONS (I2)
AC_ASSERTIONS
Processes
Physical Name: SX_PROCESS
Description: This table contains the information relating to the Process compliance object.
Primary Key: PROCESS_ID
Indices: 5
Column Name
Description
Native Type
PROCESS_ID

object.
NUMBER(38,0)
PR_ADDITIONAL_DESCRIPTION
May be used to provide HTMLformatted information about the

compliance object.
VARCHAR2(4000)
PR_CREATIONDATE
DATE
PR_CREATOR

NUMBER(38,0)
PR_CYCLE_OWNER
May be used to assign the highestlevel of responsibility for the

process cycle
VARCHAR2(4000)
PR_DESCRIPTION

compliance object
VARCHAR2(2048)
PR_FULLPATH

object.
VARCHAR2(1024)
PR_LOCKSTATUS

modified
VARCHAR2(256)
PR_MODIFIEDDATE

modified
DATE
PR_NAME

object.
VARCHAR2(4000)
PR_PARENTFOLDERID

folder of the compliance object.
NUMBER(38,0)
PR_SOXURL

VARCHAR2(4000)
PR_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
140
Table of Indices
Index Name
Table Column
IX1_SX_PROCESS (I1)
PR_CREATOR
IX2_SX_PROCESS (I2)
PR_FULLPATH
IX3_SX_PROCESS (I3)
PR_LOCKSTATUS
IX4_SX_PROCESS (I4)
PR_NAME
IX5_SX_PROCESS (I5)
PR_PARENTFOLDERID
Sub-Processes
Physical Name: SX_SUBPROCESS
Description: This table contains the information relating to sub-process compliance objects.
Primary Key: SUBPROCESS_ID
Indices: 11
Column Name
Description
Native Type
PROCESS_ID

object.
NUMBER(38,0)
PR_ADDITIONAL_DESCRIPTION
May be used to enter XHTMLformatted information about the

process.
VARCHAR2(256)
PR_CREATIONDATE
Date the compliance object was

created
DATE
PR_CREATOR

NUMBER(38,0)
PR_DESCRIPTION

compliance object
VARCHAR2(2048)
PR_EXPORTLABEL
Descriptive label assigned to the

level of the process hierarchy
VARCHAR2(256)
PR_FULLPATH

object.
VARCHAR2(1024)
PR_LOCKSTATUS

modified
VARCHAR2(256)
PR_MANAGEMENT_PRIORITY
May be used to assign the level of

importance accorded by
Management. The potential values
are High, Medium, Low, or Not
Determined (default).
VARCHAR2(256)
PR_MODIFIEDDATE

modified
DATE
PR_NAME

object.
VARCHAR2(4000)
PR_NESTINGLEVEL
Level of the sub-account in the

process hierarchy.
NUMBER
141
Column Name
Description
Native Type
PR_NESTINGPATH

processes, if any.
VARCHAR2(4000)
PR_PARENTFOLDERID

folder of the compliance object.
NUMBER(38,0)
PR_SOXURL

VARCHAR2(4000)
PR_SUBPROCESS_OWNER
May be used to assign the highestlevel of responsibility for the subprocess transaction.
VARCHAR2(256)
PR_TARGET_DESIGN_RATING
May be used to set a goal for the

design of the process. Possible
values are Unreliable, Informal,
Standardized, Monitored,
Optimized, or Not Determined
(default).
VARCHAR2(256)
PR_VERSIONID

NUMBER(38,0)
TRANSACTION
Name of the top level process, if

any.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_SUBPROCESS (I1)
PR_CREATOR
PR_EXPORTLABEL
PR_FULLPATH
PR_LOCKSTATUS
PR_MANAGEMENT_PRIORITY
PR_NAME
PR_NESTINGLEVEL
PR_NESTINGPATH
PR_PARENTFOLDERID
PR_TARGET_DESIGN_RATING
142
Control Objectives
Physical Name: SX_CONTROLOBJECTIVE
Description: This table contains the information relating to the Control Objective compliance
object.
Primary Key: CONTROLOBJECTIVE_ID
Indices: 5
Column Name
Description
Native Type
CONTROLOBJECTIVE_ID

object.
NUMBER(38,0)
CO_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
CO_CATEGORY
Obsolete field.
VARCHAR2(4000)
CO_COSO_OBJECTIVE_CATEGORY
May be used to identify one or

more of the COSO objective
categories that apply to this
control objective.
VARCHAR2(256)
CO_CREATIONDATE

created
DATE
CO_CREATOR

NUMBER(38,0)
CO_DESCRIPTION
The user-created description of

the compliance object
VARCHAR2(2048)
CO_FULLPATH

object.
VARCHAR2(1024)
CO_LOCKSTATUS
Denotes whether the object can

be modified
VARCHAR2(256)
CO_MODIFIEDDATE

modified
DATE
CO_NAME

object.
VARCHAR2(4000)
CO_PARENTFOLDERID
The unique identifier of the

parent folder of the compliance
object.
NUMBER(38,0)
CO_SOXURL

VARCHAR2(4000)
CO_VERSIONID
The number of the current

version of the compliance object.
NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
143
Table of Indices
Index Name
Table Column
IX1_SX_CONTROLOBJECTIVE (I1)
CO_CREATOR
CO_FULLPATH
CO_LOCKSTATUS
CO_NAME
CO_PARENTFOLDERID
Control Objective COSO Objective Category

Physical Name: SX_CONTROLOBJECTIVE_COSO_OBJEC
Foreign Key: CONTROLOBJECTIVE_ID
Foreign Key Reference: SX_CONTROLOBJECTIVE.CONTROLOBJECTIVE_ID
Indices: 2
Column Name
Description
Native Type
CONTROLOBJECTIVE_ID
NUMBER(38,0)

control objective.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_CONTROLOBJECTIVE_
COSO_O (I1)
CONTROLOBJECTIVE_ID
IX1_SX_CONTROLOBJECTIVE_
COSO_O (I2)
144
Risk
Physical Name: SX_RISK
Description: This table contains the information relating to the Risk compliance object.
Primary Key: RISK_ID
Indices: 12
Column Name
Description
Native Type
RISK_ID

object.
NUMBER(38,0)
RI_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
RI_ASSERTIONS
Obsolete field.
VARCHAR2(4000)
RI_COSO_OBJECTIVE_CATEGORY

control objective.
VARCHAR2(256)
RI_CREATIONDATE

created
DATE
RI_CREATOR

NUMBER(38,0)
RI_DESCRIPTION

VARCHAR2(2048)
RI_FULLPATH

object.
VARCHAR2(1024)
RI_GENERAL_GUIDANCE
May be used to provide

information to control designers
about how this risk may best be
moderated.
VARCHAR2(4000)
RI_IMPACT
May be used to measure the

importance of the particular risk.
Values are High, Medium, Low,
and Unknown.
VARCHAR2(256)
RI_LIKELYHOOD
How often the risk is likely to

occur within a financial reporting
period. Values can be High,
Medium, Low, and Unknown.
VARCHAR2(256)
RI_LOCKSTATUS

be modified
VARCHAR2(256)
RI_MODIFIEDDATE

modified
DATE
RI_NAME

object.
VARCHAR2(4000)
RI_PARENTFOLDERID

object.
NUMBER(38,0)
145
Column Name
Description
Native Type
RI_RISK_IN_SCOPE
May be used to determine

whether the risk is significant
from a Sarbanes-Oxley Act
perspective. Possible values are
Yes, No, or Not Determined
(default).
VARCHAR2(256)
RI_SOXURL

VARCHAR2(4000)
RI_TARGET_DESIGN_RATING
May be used to set a goal for the

design of the process. Possible
values are Unreliable, Informal,
Standardized, Monitored,
Optimized, or Not Determined
(default).
VARCHAR2(256)
RI_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_RISK (I1)
RI_CREATOR
IX2_SX_RISK (I2)
RI_FULLPATH
IX3_SX_RISK (I3)
RI_IMPACT
IX4_SX_RISK (I4)
RI_LIKELYHOOD
IX5_SX_RISK (I5)
RI_LOCKSTATUS
IX6_SX_RISK (I6)
RI_NAME
IX7_SX_RISK (I7)
RI_PARENTFOLDERID
IX8_SX_RISK (I8)
RI_RISK_IN_SCOPE
IX9_SX_RISK (I9)
RI_TARGET_DESIGN_RATING
146
Risk Assertions
Physical Name: SX_RISK_ASSERTIONS
Description: This table contains information relating to risk assertions.
Foreign Key: RISK_ID
Foreign Key Reference: SX_RISK.RISK_ID
Indices: 2
Column Name
Description
Native Type
RISK_ID
NUMBER(38,0)
RI_ASSERTIONS

that must be made on the risk.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_RISK_ASSERTIONS (I1)
RISK_ID
IX2_SX_RISK_ASSERTIONS (I2)
RI_ASSERTIONS
Risk COSO Objective Category

Physical Name: SX_RISK_COSO_OBJECTIVE_CATEGOR
Foreign Key: RISK_ID
Foreign Key Reference: SX_RISK.RISK_ID
Indices: 2
Column Name
Description
Native Type
RISK_ID
NUMBER(38,0)

control objective.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_RISK_COSO_OBJECTIVE_CAT (I1)
RISK_ID
IX1_SX_RISK_COSO_OBJECTIVE_CAT (I2)
147
Controls
Physical Name: SX_CONTROL
Description: This table contains the information relating to the Control compliance object.
Primary Key: CONTROL_ID
Indices: 12
Column Name
Description
Native Type
CONTROL_ID

object.
NUMBER(38,0)
CT_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
CT_ASSERTIONS_CONTROLLED
Indicates the financial statement

assertions affected by the
control.
VARCHAR2(4000)
CT_CLASSIFICATION
May be used to determine if this

is a key control and allow the
determination of when, how, and
how often the control must be
tested.
VARCHAR2(256)
CT_CREATIONDATE

created
DATE
CT_CONTROL_METHOD
Identifies how the control is

implemented.
VARCHAR2(256)
CT_CONTROL_OWNER
Identifies the user responsible for

the control
VARCHAR2(4000)
CT_COSO_COMPONENT
May be used to determine to

which of the COSO components
the control best applies.
VARCHAR2(256)
CT_CREATOR

NUMBER(38,0)
CT_DESCRIPTION

VARCHAR2(2048)
CT_DESIGN_EFFECTIVENESS
Attests to the effectiveness of the

design of the control.
VARCHAR2(256)
CT_DOCUMENTATION_LOCATION
Identifies where or how

documentation about the control
is stored.
VARCHAR2(4000)
CT_DOES_THE_CONTROL_OWNE
R_PERF
Identifies whether the control

owner is the person responsible
for performing the control
activity.
VARCHAR2(256)
CT_FREQUENCY_OF_CONTROL_A
CTIVI
Identifies the frequency with

which the control is performed.
VARCHAR2(256)
CT_FULLPATH

object.
VARCHAR2(1024)
CT_IT_SYSTEM
Denotes what IT systems were

affected.
VARCHAR2(256)
148
Column Name
Description
Native Type
CT_LOCKSTATUS

be modified
VARCHAR2(256)
CT_MODIFIEDDATE

modified
DATE
CT_NAME

object.
VARCHAR2(4000)
CT_OPERATING_EFFECTIVNESS
Attests to the operational

effectiveness of the control.
VARCHAR2(256)
CT_PARENTFOLDERID

object.
NUMBER(38,0)
CT_POSSIBLE_TEST_TYPES
Determines the different ways in

which the control may be tested.
VARCHAR2(4000)
CT_SITES_COVERED
Denotes which sites are covered

by the control.
VARCHAR2(4000)
CT_SOXURL

VARCHAR2(4000)
CT_VERSIONID

NUMBER(38,0)
CT_WHO_PERFORMS_CONTROL
If the control owner does not

perform the control, this field
identifies the user assigned to
perform the control.
VARCHAR2(4000)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_CONTROL (I1)
CT_CLASSIFICATION
IX2_SX_CONTROL (I2)
CT_CONTROL_METHOD
IX3_SX_CONTROL (I3)
CT_COSO_COMPONENT
IX4_SX_CONTROL (I4)
CT_CREATOR
IX5_SX_CONTROL (I5)
CT_DESIGN_EFFECTIVENESS
IX6_SX_CONTROL (I6)
CT_DOES_THE_CONTROL_OWNER_PERF
IX7_SX_CONTROL (I7)
CT_FREQUENCY_OF_CONTROL_ACTIVI
IX8_SX_CONTROL (I8)
CT_FULLPATH
IX9_SX_CONTROL (I9)
CT_LOCKSTATUS
IX10_SX_CONTROL (I10)
CT_NAME
CT_OPERATING_EFFECTIVENESS
CT_PARENTFOLDERID
149
Control Assertions Controlled

Physical Name: SX_CONTROL_ASSERTIONS_CONTROLL
Foreign Key: CONTROL_ID
Foreign Key Reference: SX_CONTROL.CONTROL_ID
Indices: 2
Column Name
Description
Native Type
CONTROL_ID
NUMBER(38,0)
Indicates the financial statement

assertions affected by the
control.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_CONTROL_ASSERTIONS_
CONT (I1)
CONTROL_ID
IX2_SX_CONTROL_ASSERTIONS_
CONT (I2)
Control IT Systems
Physical Name: SX_CONTROL_IT_SYSTEM
Indices: 2
Column Name
Description
Native Type
CONTROL_ID
NUMBER(38,0)
CT_IT_SYSTEM
Denotes which IT systems were

affected.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_CONTROL_IT_SYSTEM (I1)
CONTROL_ID
IX2_SX_CONTROL_IT_SYSTEM (I2)
CT_IT_SYSTEM
150
Control Possible Test Types

Physical Name: SX_CONTROL_POSSIBLE_TEST_TYPES
Indices: 2
Column Name
Description
Native Type
CONTROL_ID
NUMBER(38,0)
Determines the different ways in

which the control may be tested.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_CONTROL_POSSIBLE_
TEST_T (I1)
CONTROL_ID
IX2_SX_CONTROL_POSSIBLE_
TEST_T (I2)
Control Sites Covered

Physical Name: SX_CONTROL_SITES_COVERED
Indices: 2
Column Name
Description
Native Type
CONTROL_ID
NUMBER(38,0)
CT_SITES_COVERED
Denotes which sites are covered

by the control.
VARCHAR2(256)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_CONTROL_SITES_
COVERED (I1)
CONTROL_ID
IX2_SX_CONTROL_SITES_
COVERED (I2)
CT_SITES_COVERED
151
Test
Physical Name: SX_TEST
Description: This table contains the information relating to the Test compliance object.
Primary Key: TEST_ID
Indices: 8
Column Name
Description
Native Type
TEST_ID

object.
NUMBER(38,0)
TE_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
TE_CREATIONDATE

created
DATE
TE_CREATOR

NUMBER(38,0)
TE_DESCRIPTION

VARCHAR2(2048)
TE_FULLPATH

object.
VARCHAR2(1024)
TE_GUIDANCE_FOR_TESTER
May be used to document any

additional information that the
Test Performer or Test Reviewer
may find useful when performing
the test.
VARCHAR2(4000)
TE_LOCKSTATUS

be modified
VARCHAR2(256)
TE_MODIFIEDDATE

modified
DATE
TE_NAME

object.
VARCHAR2(4000)
TE_PARENTFOLDERID

object.
NUMBER(38,0)
TE_SAMPLE_SIZE_USED
May be used to determine the

recommended or required sample
size to use when performing the
test.
VARCHAR2(256)
TE_SOXURL

VARCHAR2(4000)
TE_TEST_FREQUENCY
How often the test is performed.
VARCHAR2(256)
TE_TEST_FREQUENCY_OFFSET
May be used to set the date for

performing the test in number of
days after the start of the
frequency period.
NUMBER(38,0)
TE_TEST_PERFORMER
The user responsible for

performing the test
VARCHAR2(4000)
TE_TEST_REVIEWER
The user responsible for ensuring

that the test is complete.
VARCHAR2(4000)
152
Column Name
Description
Native Type
TE_TEST_TYPES_EXPECTED
Indicates the type of test to be

performed.
VARCHAR2(256)
TE_TESTING_STEPS
May be used to list the steps that

must be completed in order to
correctly perform the test.
VARCHAR2(4000)
TE_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_TEST (I1)
TE_CREATOR
IX2_SX_TEST (I2)
TE_FULLPATH
IX3_SX_TEST (I3)
TE_LOCKSTATUS
IX4_SX_TEST (I4)
TE_NAME
IX5_SX_TEST (I5)
TE_PARENTFOLDERID
IX6_SX_TEST (I6)
TE_SAMPLE_SIZE_USED
IX7_SX_TEST (I7)
TE_TEST_FREQUENCY
IX8_SX_TEST (I8)
TE_TEST_TYPES_EXPECTED
153
Test Results
Physical Name: SX_TESTRESULT
Description: This table contains the information relating to the Control compliance object.
Primary Key: TESTRESULT_ID
Indices: 11
Column Name
Description
Native Type
TESTRESULT_ID

object.
NUMBER(38,0)
TR_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
TR_CREATIONDATE

created
DATE
TR_CREATOR

NUMBER(38,0)
TR_DATE_PERFORMED
Shows the last date the test was

performed.
DATE
TR_DESCRIPTION

VARCHAR2(2048)
TR_EFFECTIVENESS
Attests to the effectiveness of the

design of the control. May be
obsolete.
VARCHAR2(256)
TR_EXCEPTION_DESCRIPTION
If an exception was found, this

field can be used to capture more
information about the exception.
VARCHAR2(4000)
TR_EXCEPTIONS
Indicates whether any exceptions

were found when performing the
test.
VARCHAR2(256)
TR_FULLPATH
VARCHAR2(1024)
TR_IS_THIS_A_RETEST
Indicates whether the test is

being performed again to check a
previous result.
VARCHAR2(256)
TR_LOCKSTATUS

be modified
VARCHAR2(256)
TR_MODIFIEDDATE

modified
DATE
TR_NAME

object.
VARCHAR2(4000)
TR_PARENTFOLDERID

object.
NUMBER(38,0)
TR_PERFORMED_BY
The user name of the person who

performed the test.
VARCHAR2(4000)
TR_PERSON_INQUIRED_OF_
OBSERVED
Indicates whether the person

involved with the performance of
the control being tested was
actually observed during the
performance of the control.
VARCHAR2(4000)
154
Column Name
Description
Native Type
TR_REVIEWED_BY
Indicates the user who reviewed

the test result.
VARCHAR2(4000)
TR_REVEWER_CONCLUSION
Indicates the objective

assessment of the reviewer of the
test result.
VARCHAR2(256)
TR_REVIEWER_CONCLUSION_
COMMENT
Provides an area for the reviewer

to mark down his subjective
assessment of the test results in
additional detail.
VARCHAR2(4000)
TR_SAMPLE_SIZE_USED
Identifies the sample size used

during the test.
VARCHAR2(256)
TR_SOXURL

VARCHAR2(4000)
TR_TEST_RESULT
Displays the result of the test.
VARCHAR2(256)
TR_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_TESTRESULT (I1)
TR_CREATOR
TR_EFFECTIVENESS
TR_EXCEPTIONS
TR_FULLPATH
TR_IS_THIS_A_RETEST
TR_LOCKSTATUS
TR_NAME
TR_PARENTFOLDERID
TR_REVIEWER_CONCLUSION
TR_SAMPLE_SIZE_USED
TR_TEST_RESULT
155
Issues
Physical Name: SX_ISSUE
Description: This table contains the information relating to Issues.
Primary Key: ISSUE_ID
Indices: 10
Column Name
Description
Native Type
ISSUE_ID
NUMBER(38,0)
IS_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
IS_ASSIGNEE
Indicates the user who is

responsible for resolving the
issue.
VARCHAR2(4000)
IS_CREATIONDATE
Date the issue was created
DATE
IS_CREATOR

NUMBER(38,0)
IS_DESCRIPTION

VARCHAR2(2048)
IS_DETAIL
Hidden field - do not use.
VARCHAR2(4000)
IS_FULLPATH

object.
VARCHAR2(1024)
IS_ISSUE_CREATED_BY
Lists the user who created the

issue.
VARCHAR2(4000)
IS_ISSUE_IMPACT
Identifies the severity of the

issue.
VARCHAR2(256)
IS_ISSUE_PROBABILITY
The likelihood that the issue will

occur.
VARCHAR2(256)
IS_ISSUE_TYPE
Identifies the nature of the issue

as it relates to the activity being
performed.
VARCHAR2(256)
IS_LOCKSTATUS

be modified
VARCHAR2(256)
IS_MODIFIEDDATE

modified
DATE
IS_NAME

object.
VARCHAR2(4000)
IS_PARENTFOLDERID

object.
NUMBER(38,0)
IS_ROOT_CAUSE_DESCRIPTION
Can be used to provide details

about the selection of the Root
Cause Type.
VARCHAR2(4000)
IS_ROOT_CAUSE_TYPE
May be used to objectively select

the primary reason for the issue
to occur.
VARCHAR2(256)
156
Column Name
Description
Native Type
IS_SOXURL

VARCHAR2(4000)
IS_STATUS
Displays the status of the issue.
VARCHAR2(256)
IS_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_ISSUE (I1)
IS_CREATOR
IX2_SX_ISSUE (I2)
IS_FULLPATH
IX3_SX_ISSUE (I3)
IS_ISSUE_IMPACT
IX4_SX_ISSUE (I4)
IS_ISSUE_PROBABILITY
IX5_SX_ISSUE (I5)
IS_ISSUE_TYPE
IX6_SX_ISSUE (I6)
IS_LOCKSTATUS
IX7_SX_ISSUE (I7)
IS_NAME
IX8_SX_ISSUE (I8)
TR_PARENTFOLDERID
IX9_SX_ISSUE (I9)
IS_ROOT_CAUSE_TYPE
IX10_SX_ISSUE (I10)
IS_STATUS
157
Action Items
Physical Name: SX_ACTIONITEM
Description: This table contains information relating to Action Items.
Primary Key: ACTIONITEM_ID
Indices: 6
Column Name
Description
Native Type
ACTIONITEM_ID
NUMBER(38,0)
AI_ACTION_ITEM_TYPE
Assigns a classification system to

the action item.
VARCHAR2(4000)
AI_ACTUAL_COMPLETION_DATE
Indicates when the action item

was actually completed.
DATE
AI_ADDITIONAL_DESCRIPTION

compliance object.
VARCHAR2(4000)
AI_ASSIGNEE
Indicates the user who is

responsible for resolving the
action item.
VARCHAR2(4000)
AI_BUSINESS_LOCATION
Can be used to identify the

particular location associated
with the action item.
VARCHAR2(4000)
AI_COMMENT
May be used to enter information

each time the action item is
updated.
VARCHAR2(4000)
AI_CREATIONDATE
Date the issue was created
DATE
AI_CREATOR

NUMBER(38,0)
AI_DESCRIPTION

VARCHAR2(2048)
AI_DETAIL
Hidden field - do not use.
VARCHAR2(4000)
AI_DUE_DATE
Hidden or obsolete field - use

AI_EXPECTED_DUE_DATE.
DATE
AI_EXPECTED_COMPLETION_
DATE
Sets the expected completion

date of the action item.
DATE
AI_FULLPATH

object.
VARCHAR2(1024)
AI_LOCKSTATUS

be modified
VARCHAR2(256)
AI_MODIFIEDDATE

modified
DATE
AI_NAME

object.
VARCHAR2(4000)
AI_PARENTFOLDERID

object.
NUMBER(38,0)
AI_PERCENT_COMPLETE
Indicates the progress of work on

the action item.
NUMBER(38,0)
158
Column Name
Description
Native Type
AI_PREDECESSOR
Identifies which action item (if

any) must be completed before
work on the current action item
can begin.
VARCHAR2(4000)
AI_SOXURL

VARCHAR2(4000)
AI_START_DATE
Indicates when work on the

action item was started.
DATE
AI_STATUS
Displays the status of the action

item.
VARCHAR2(256)
AI_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
Table of Indices
Index Name
Table Column
IX1_SX_ACTIONITEM (I1)
AI_CREATOR
AI_FULLPATH
AI_LOCKSTATUS
AI_NAME
AI_PARENTFOLDERID
AI_STATUS
Action Item Type

Physical Name: SX_ACTIONITEM_ACTION_ITEM_TYPE
Description: This table contains information relating to Action Items Types.
Foreign Key: ACTIONITEM_ID
Foreign Key Reference: SX_ACTIONITEM.ACTIONITEM_ID
Indices: 2
Column Name
Description
Native Type
ACTIONITEM_ID
NUMBER(38,0)
AI_ACTION_ITEM_TYPE
Assigns a classification system to

the action item.
VARCHAR2(4000)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
159
Table of Indices
Index Name
Table Column
IX1_SX_ACTIONITEM_ACTION_
ITEM_ (I1)
ACTIONITEM_ID
IX2_SX_ACTIONITEM_ACTION_
ITEM_ (I2)
AI_ACTION_ITEM_TYPE
Signatures
Physical Name: SX_SIGNOFF
Description: This table contains information relating to signatures.
Primary Key: SIGNOFF_ID
Indices: 6
Column Name
Description
Native Type
SIGNOFF_ID
NUMBER(38,0)
SI_COMMENTS
May be used to enter information

when the signature is created.
VARCHAR2(4000)
SI_CREATIONDATE
Date the signature was created
DATE
SI_CREATOR

NUMBER(38,0)
SI_DESCRIPTION

VARCHAR2(2048)
SI_FULLPATH
VARCHAR2(1024)
SI_LOCKSTATUS

be modified
VARCHAR2(256)
SI_MODIFIEDDATE

modified
DATE
SI_NAME

object.
VARCHAR2(4000)
SI_PARENTFOLDERID

object.
NUMBER(38,0)
SI_SOXURL

VARCHAR2(4000)
SI_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
160
Table of Indices
Index Name
Table Column
IX1_SX_SIGNOFF (I1)
SI_CREATOR
IX2_SX_SIGNOFF (I2)
SI_FULLPATH
IX3_SX_SIGNOFF (I3)
SI_LOCKSTATUS
IX4_SX_SIGNOFF (I4)
SI_NAME
IX5_SX_SIGNOFF (I5)
SI_PARENTFOLDERID
IX6_SX_SIGNOFF (I6)
SI_STATUS
Files
Physical Name: SX_FILE
Description: This table contains information relating to files.
Primary Key: FILE_ID
Indices: 6
Column Name
Description
Native Type
FILE_ID
NUMBER(38,0)
FI_CREATIONDATE
DATE
FI_CREATOR

NUMBER(38,0)
FI_DESCRIPTION

VARCHAR2(2048)
FI_FULLPATH
VARCHAR2(1024)
FI_LOCKSTATUS

be modified
VARCHAR2(256)
FI_MODIFIEDDATE

modified
DATE
FI_NAME

object.
VARCHAR2(4000)
FI_PARENTFOLDERID

object.
NUMBER(38,0)
FI_SOXURL

VARCHAR2(4000)
FI_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
161
Table of Indices
Index Name
Table Column
IX1_SX_FILE (I1)
FI_CREATOR
IX2_SX_FILE (I2)
FI_FULLPATH
IX3_SX_FILE (I3)
FI_LOCKSTATUS
IX4_SX_FILE (I4)
FI_NAME
IX5_SX_FILE (I5)
FI_PARENTFOLDERID
Links
Physical Name: SX_LINK
Primary Key: LINK_ID
Indices: 6
Column Name
Description
Native Type
LINK_ID
NUMBER(38,0)
LI_CREATIONDATE
DATE
LI_CREATOR

NUMBER(38,0)
LI_DESCRIPTION

VARCHAR2(2048)
LI_FULLPATH
VARCHAR2(1024)
LI_LOCKSTATUS

be modified
VARCHAR2(256)
LI_MODIFIEDDATE

modified
DATE
LI_NAME

object.
VARCHAR2(4000)
LI_PARENTFOLDERID

object.
NUMBER(38,0)
LI_SOXURL

VARCHAR2(4000)
LI_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
162
Table of Indices
Index Name
Table Column
IX1_SX_LINK (I1)
LI_CREATOR
IX2_SX_LINK (I2)
LI_FULLPATH
IX3_SX_LINK (I3)
LI_LOCKSTATUS
IX4_SX_LINK (I4)
LI_NAME
IX5_SX_LINK (I5)
LI_PARENTFOLDERID
Milestones
Physical Name: SX_MILESTONE
Primary Key: MILESTONE_ID
Indices: 6
Column Name
Description
Native Type
MILESTONE_ID
NUMBER(38,0)
MI_CREATIONDATE
DATE
MI_CREATOR

NUMBER(38,0)
MI_DESCRIPTION

VARCHAR2(2048)
MI_FULLPATH
VARCHAR2(1024)
MI_LOCKSTATUS

be modified
VARCHAR2(256)
MI_MODIFIEDDATE

modified
DATE
MI_NAME

object.
VARCHAR2(4000)
MI_PARENTFOLDERID

object.
NUMBER(38,0)
MI_SOXURL

VARCHAR2(4000)
MI_VERSIONID

NUMBER(38,0)
REPORTING _PERIOD

reporting period.
VARCHAR2(256)
163
Table of Indices
Index Name
Table Column
IX1_SX_MILESTONE (I1)
MI_CREATOR
MI_FULLPATH
MI_LOCKSTATUS
MI_NAME
MI_PARENTFOLDERID
164
Compliance Object Relationship Tables

Relationship tables represent the transitive many-to-many relationships between SOX Express
compliance objects.
Each relationship table has four columns - parent object ID, child object ID, the distance
between parent and child (the nesting level), and the reporting period label. If the distance
between the parent and child objects is 1, the objects are linked directly.
Each relationship table has an index on the parent ID and child ID columns, and foreign keys
referencing the respective compliance object tables.
Business Entity Relationships

Table Name
Parent Object ID
Child Object ID
SX__ENTITY_ENTITY
PARENTENTITY_ID
CHILDENTITY_ID
SX__ENTITY_ACCOUNT
ENTITY_ID
ACCOUNT_ID
SX__ENTITY_SUBACCOUNT
ENTITY_ID
SUBACCOUNT_ID
SX__ENTITY_PROCESS
ENTITY_ID
PROCESS_ID
SX__ENTITY_SUBPROCESS
ENTITY_ID
SUBPROCESS_ID
SX__ENTITY_CONTROLOBJECTIVE
ENTITY_ID
CONTROLOBJECTIVE_ID
SX__ENTITY_RISK
ENTITY_ID
RISK_ID
SX__ENTITY_CONTROL
ENTITY_ID
CONTROL_ID
SX__ENTITY_TEST
ENTITY_ID
TEST_ID
SX__ENTITY_TESTRESULT
ENTITY_ID
TESTRESULT_ID
SX__ENTITY_ISSUE
ENTITY_ID
ISSUE_ID
SX__ENTITY_ACTIONITEM
ENTITY_ID
ACTIONITEM_ID
SX__ENTITY_SIGNOFF
ENTITY_ID
SIGNOFF_ID
SX__ENTITY_FILE
ENTITY_ID
FILE_ID
SX__ENTITY_LINK
ENTITY_ID
LINK_ID
Account Relationships
Table Name
Parent Object ID
Child Object ID
SX__ACCOUNT_SUBACCOUNT
ACCOUNT_ID
SUBACCOUNT_ID
SX__ACCOUNT_ISSUE
ACCOUNT_ID
ISSUE_ID
SX__ACCOUNT_ACTIONITEM
ACCOUNT_ID
ACTIONITEM_ID
SX__ACCOUNT_SIGNOFF
ACCOUNT_ID
SIGNOFF_ID
SX__ACCOUNT_FILE
ACCOUNT_ID
FILE_ID
SX__ACCOUNT_LINK
ACCOUNT_ID
LINK_ID
165
Sub-Account Relationships
Table Name
Parent Object ID
Child Object ID
SX__SUBACCOUNT_SUBACCOUNT
PARENTSUBACCOUNT_ID
CHILDSUBACCOUNT_ID
SX__SUBACCOUNT_ISSUE
SUBACCOUNT_ID
ISSUE_ID
SX__SUBACCOUNT_ACTIONITEM
SUBACCOUNT_ID
ACTIONITEM_ID
SX__SUBACCOUNT_SIGNOFF
SUBACCOUNT_ID
SIGNOFF_ID
SX__SUBACCOUNT_FILE
SUBACCOUNT_ID
FILE_ID
SX__SUBACCOUNT_LINK
SUBACCOUNT_ID
LINK_ID
Process Relationships
Table Name
Parent Object ID
Child Object ID
SX__PROCESS_SUBPROCESS
PROCESS_ID
SUBPROCESS_ID
SX__PROCESS_ACCOUNT
PROCESS_ID
ACCOUNT_ID
SX__PROCESS_SUBACCOUNT
PROCESS_ID
SUBACCOUNT_ID
SX__PROCESS_CONTROLOBJECTIVE
PROCESS_ID
CONTROLOBJECTIVE_ID
SX__PROCESS_RISK
PROCESS_ID
RISK_ID
SX__PROCESS_CONTROL
PROCESS_ID
CONTROL_ID
SX__PROCESS_TEST
PROCESS_ID
TEST_ID
SX__PROCESS_TESTRESULT
PROCESS_ID
TESTRESULT_ID
SX__PROCESS_ISSUE
PROCESS_ID
ISSUE_ID
SX__PROCESS_ACTIONITEM
PROCESS_ID
ACTIONITEM_ID
SX__PROCESS_SIGNOFF
PROCESS_ID
SIGNOFF_ID
SX__PROCESS_FILE
PROCESS_ID
FILE_ID
SX__PROCESS_LINK
PROCESS_ID
LINK_ID
166
Sub-Process Relationships
Table Name
Parent Object ID
Child Object ID
SX__SUBPROCESS_SUBPROCESS
PARENTSUBPROCESS_ID
CHILDSUBPROCESS_ID
SX__SUBPROCESS_ACCOUNT
SUBPROCESS_ID
ACCOUNT_ID
SX__SUBPROCESS_SUBACCOUNT
SUBPROCESS_ID
SUBACCOUNT_ID
SX__SUBPROCESS_CONTROLOBJ
SUBPROCESS_ID
CONTROLOBJECTIVE_ID
SX__SUBPROCESS_RISK
SUBPROCESS_ID
RISK_ID
SX__SUBPROCESS_CONTROL
SUBPROCESS_ID
CONTROL_ID
SX__SUBPROCESS_TEST
SUBPROCESS_ID
TEST_ID
SX__SUBPROCESS_TESTRESULT
SUBPROCESS_ID
TESTRESULT_ID
SX__SUBPROCESS_ISSUE
SUBPROCESS_ID
ISSUE_ID
SX__SUBPROCESS_ACTIONITEM
SUBPROCESS_ID
ACTIONITEM_ID
SX__SUBPROCESS_SIGNOFF
SUBPROCESS_ID
SIGNOFF_ID
SX__SUBPROCESS_FILE
SUBPROCESS_ID
FILE_ID
SX__SUBPROCESS_LINK
SUBPROCESS_ID
LINK_ID
Control Objective Relationships

Table Name
Parent Object ID
Child Object ID
SX__CONTROLOBJECTIVE_RISK
CONTROLOBJECTIVE_ID
RISK_ID
SX__CONTROLOBJECTIVE_CONTROL
CONTROLOBJECTIVE_ID
CONTROL_ID
SX__CONTROLOBJECTIVE_TEST
CONTROLOBJECTIVE_ID
TEST_ID
SX__CONTROLOBJECTIVE_TESTRESUL
CONTROLOBJECTIVE_ID
TESTRESULT_ID
SX__CONTROLOBJECTIVE_ISSUE
CONTROLOBJECTIVE_ID
ISSUE_ID
SX__CONTROLOBJECTIVE_ACTIONITE
CONTROLOBJECTIVE_ID
ACTIONITEM_ID
SX__CONTROLOBJECTIVE_SIGNOFF
CONTROLOBJECTIVE_ID
SIGNOFF_ID
SX__CONTROLOBJECTIVE_FILE
CONTROLOBJECTIVE_ID
FILE_ID
SX__CONTROLOBJECTIVE_LINK
CONTROLOBJECTIVE_ID
LINK_ID
167
Control Relationships
Table Name
Parent Object ID
Child Object ID
SX__CONTROL_TEST
CONTROL_ID
TEST_ID
SX__CONTROL_TESTRESULT
CONTROL_ID
TESTRESULT_ID
SX__CONTROL_ISSUE
CONTROL_ID
ISSUE_ID
SX__CONTROL_ACTIONITEM
CONTROL_ID
ACTIONITEM_ID
SX__CONTROL_SIGNOFF
CONTROL_ID
SIGNOFF_ID
SX__CONTROL_FILE
CONTROL_ID
FILE_ID
SX__CONTROL_LINK
CONTROL_ID
LINK_ID
Test Relationships
Table Name
Parent Object ID
Child Object ID
SX__TEST_TESTRESULT
TEST_ID
TESTRESULT_ID
SX__TEST_ISSUE
TEST_ID
ISSUE_ID
SX__TEST_ACTIONITEM
TEST_ID
ACTIONITEM_ID
SX__TEST_SIGNOFF
TEST_ID
SIGNOFF_ID
SX__TEST_FILE
TEST_ID
FILE_ID
SX__TEST_LINK
TEST_ID
LINK_ID
Test Result Relationships

Table Name
Parent Object ID
Child Object ID
SX__TESTRESULT_ISSUE
TESTRESULT_ID
ISSUE_ID
SX__TESTRESULT_ACTIONITEM
TESTRESULT_ID
ACTIONITEM_ID
SX__TESTRESULT_FILE
TESTRESULT_ID
FILE_ID
SX__TESTRESULT_LINK
TESTRESULT_ID
LINK_ID
Issue Relationships
Table Name
Parent Object ID
Child Object ID
SX__ISSUE_ACTIONITEM
ISSUE_ID
ACTIONITEM_ID
SX__ISSUE_FILE
ISSUE_ID
FILE_ID
SX__ISSUE_LINK
ISSUE_ID
LINK_ID
168
Test Result Relationships

Table Name
Parent Object ID
Child Object ID
SX__TESTRESULT_ISSUE
TESTRESULT_ID
ISSUE_ID
SX__TESTRESULT_ACTIONITEM
TESTRESULT_ID
ACTIONITEM_ID
SX__TESTRESULT_FILE
TESTRESULT_ID
FILE_ID
SX__TESTRESULT_LINK
TESTRESULT_ID
LINK_ID
Action Item Relationships

Table Name
Parent Object ID
Child Object ID
SX__ACTIONITEM_FILE
ACTIONITEM_ID
FILE_ID
SX__ACTIONITEM_LINK
ACTIONITEM_ID
LINK_ID
Table Name
Parent Object ID
Child Object ID
SX__MILESTONE_MILESTONE
PARENTMILESTONE_ID
CHILDMILESTONE_ID
SX__MILESTONE_ISSUE
MILESTONE_ID
ISSUE_ID
SX__MILESTONE_ACTIONITEM
MILESTONE_ID
ACTIONITEM_ID
SX__MILESTONE_FILE
MILESTONE_ID
FILE_ID
SX__MILESTONE_LINK
MILESTONE_ID
LINK_ID
169
Master Relationships Table

The Master Relationships table contains all of the possible transitive relationships between
parent and child compliance objects.
Physical Name: SX__ASSOCIATION
Primary Key: None
Indices: 4
Column Name
Description
Native Type
PARENT
Parent resource ID
NUMBER(38,0)
PARENT_CTYPE_ID
Parent content type ID
NUMBER(38,0)
PARENTTYPE
Parent type name
VARCHAR2(256)
CHILD
Child resource ID
NUMBER(38,0)
CHILD_CTYPE_ID
Child content type ID
NUMBER(38,0)
CHILDTYPE
Child type name
VARCHAR2(256)
CHILD_LEVEL
Distance between parent and child
NUMBER(38,0)
REPORTING_PERIOD
User specified label
VARCHAR2(256)
Table of Indices
Index Name
Table Column
SX__ASSOC_PARENT_CTYPE_NDX
PARENT_CTYPE_ID
SX__ASSOC_PARENT_NDX
PARENT
SX_ASSOC_CHILD_CTYPE_NDX
CHILD_CTYPE_ID
SX_ASSOC_CHILD_NDX
CHILD
170
Security Tables
Security tables are used to create security reports and implement the SOX Express security
filters inside the reporting frameworks that support this feature.
In the Effective Rights table, all of the permission flags can be set to one of the following
values:
Positive one (1) - permission is granted

Negative one (-1) - permission is denied
NULL or zero (0) - permission is not explicitly defined for the object, which effectively
denies access
Effective Rights
Physical Name: EFFECTIVE_RIGHTS
Description: This table contains information relating to the users ability to modify the
resource.
Primary Keys: RESOURCEID, ACTORID
Indices: 1
Column Name
Description
Native Type
RESOURCEID
The unique ID of the folder.
NUMBER(38,0)
ACTORID
The unique ID of the user.
NUMBER(38,0)
READACCESS
Whether the actor has permission to view

the contents of the folder
NUMBER(2,0)
RELATEACCESS
Whether the actor has permission to

associate objects to the contents of the
folder
NUMBER(2,0)
WRITEACCESS

modify the contents of the folder
NUMBER(2,0)
DELETEACCESS
Whether the actor has permission to delete

the contents of the folder
NUMBER(2,0)
MANAGEACCESS

modify the folder ACLs
NUMBER(2,0)
Table of Indices
Index Name
EFFECTIVE_RIGHTS_UN (I1)
Table Columns
ACTORID, RESOURCEID
171
Folders
Physical Name: FOLDERS
Description: This table contains information relating to folders.
Primary Keys: RESOURCEID
Indices: 1
Column Name
Description
Native Type
RESOURCEID
The unique ID of the folder.
NUMBER(38,0)
FULLPATH
The full path of the folder in the

container hierarchy
VARCHAR2(1024)
CREATORID
The unique ID of the creator
NUMBER(38,0)
CREATIONDATE
The date the folder was created
DATE
ACLINHERITFROMPARENT
Whether the folder inherits ACLs from

the parent folders.
NUMBER(38,0)
Table of Indices
Index Name
FOLDERS_FULLPATH (I1)
Table Columns
FULLPATH
Actors
Physical Name: ACTORINFO
Description: This table contains information relating to users.
Primary Keys: ACTORID
Indices: 1
Column Name
Description
Native Type
ACTORID
The unique ID of the user.
NUMBER(38,0)
NAME
The name of the user
VARCHAR2(256)
ADMINLEVEL
Whether the user is an administrator
NUMBER(38,0)
EMAIL
The e-mail address of the user
VARCHAR2(256)
DESCRIPTION
The description of the user
VARCHAR2(1024)
ISIMPORTED
ISHIDDEN
NUMBER(1,0)
Whether the user is shown in user
picklists
NUMBER(1,0)
IMPRTERID
NUMBER(38,0)
OPEDITED
NUMBER(38,0)
172
Table of Indices
Index Name
ACTORINFO_UN (I1)
Columns
NAME
Audit Trails
Audit trail information is represented by a single table that aggregates change events to
compliance objects and the relationships between them.
Audit Trail
Physical Name: SX_AUDIT
Description: This table contains information relating to the audit trails.
Primary Keys: None.
Indices: 3
Column Name
Description
Native Type
RESOURCEID
The unique ID of the resource
NUMBER(38,0)
VERSIONID
The version ID of the resource
NUMBER(38,0)
RESOURCE_NAME
The name of the resource
VARCHAR2(256)
RESOURCE_TYPE
The content type of the resource
VARCHAR2(256)
WHO
The user who made the change
VARCHAR2(230)
WHEN
When the change was made
DATE
WHICH_PROPERTY
Identifies the property that was

changed
VARCHAR2(256)
ACTION
Identifies the action performed on the

resource
VARCHAR(7)
OLD_VALUE
The previous value of the modified

property
VARCHAR2(4000)
NEW_VALUE
The edited value of the modified

property
VARCHAR2(4000)
CHANGE
Description of the change
VARCHAR2(4000)
Table of Indices
Index Name
Columns
SX_AUDIT_RES_NDX (I1)
RESOURCEID
SX_AUDIT_VER_NDX (I2)
VERSIONID
SX_AUDIT_WHEN_NDX (I3)
WHEN
173
Integrating with
TeamMate
What is TeamMate?
TeamMate EWP (Electronic Working Paper) is an audit management
system developed by PricewaterhouseCooper (PwC) that allows
auditors to increase the efficiency of the entire auditing process.
With Sarbanes-Oxley Express support for exporting and importing data
to and from TeamMate, you can leverage your existing auditing
infrastructure to interface with your SOX Express compliance object
model.
How TeamMate and SOX Express Interact

In order to use TeamMate EWP with SOX Express, you must use a
report to select the processes you wish to audit and export the relevant
information (Risks, Controls, and Tests) to an XML file. A translation
tool then transforms the generated XML to the corresponding
TeamMate XML structure. Once the translation is complete, the
resulting file is then imported into TeamMate for the auditors to work
on.
After the auditing is completed, the results of the audit can be exported
from TeamMate and transformed back into the SOX Express format.
The audit information can then be imported into SOX Express as Test
Results, Issues, and Action Items, while the appropriate fields for each
object are updated with the auditing results.
An overview of the process looks like this:
Risks, Controls, and Tests are exported from SOX Express.

Data is transformed from SOX Express XML structure to
TeamMates XML structure.
Resulting data is imported into TeamMate.
Auditors then test as necessary.
The auditing data is then exported to an XML file.
The XML file is transformed back to SOX Express XML
structure.
Resulting file is imported into SOX Express as Test Results,
Issues, and Action Items
The compliance objects are updated with the results of the
audit testing.
Note: The TeamMate Integration Module only exports compliance

object information from the Current Reporting Period.
174
TeamMate/SOX Express Naming Schemes

The following tables explain how the different compliance objects are represented in SOX
Express and TeamMates hierarchy structure:
SOX Express Object
TeamMate Equivalent
Business Entity and Process
Project (establishing context)
Risk, Control, and Test
Procedure
TeamMate Object
SOX Express Equivalent
Procedure (with unique Test ID)
Test (already exists in SOX Express)
Test Result
Test Result
Exception (Issue)
Issue and Action Item
Exporting Data to TeamMate 175
Exporting Data to TeamMate

How Exporting Data Works
When you export data from SOX Express to TeamMate, you run a pre-defined report and select
a process (or set of processes) that you wish to export to TeamMate. When you click Export,
all of the Risks, Controls, and Tests underneath those processes (and any sub-processes
beneath them) are exported to an XML file that can be imported into TeamMate.
Because TeamMate uses a two-tiered organizational structure (Projects and Areas), while SOX
Express allows many levels of nesting, when data is exported to TeamMate, the top-level
process will be used as the Project, and the lowest level sub-process will be used as the Area.
All nesting information will be maintained as properties, but specific Areas for the intermediate
levels will not (can not) be created.
Setting Up The Schema Mapping

Before running the export procedure for the first time, you will need to set up the mapping
between your SOX Express schema and the TeamMate import schema. A sample file is provided
that maps the default SOX Standard Schema to TeamMate, but any customization you have
made to your schema must be represented in the mapping XML file.
Running the TeamMate Export Report

After completing the TIM installation procedure, a new Reporting area was created named
TeamMate that contains a new report named TeamMate Export. Running the report allows
you to choose the scope of the report by listing the available business entities.
After choosing a business entity, the report displays a list of processes contained within that
business entity. By selecting the checkbox next to a process or sub-process, that object will be
exported to the TeamMate XML file when the file is generated.
Once you have finished selecting the processes to be exported, click the Export button at the
top of the report. The report will execute and create the TeamMate XML file containing the
selected processes.
You will recieve a prompt to save the generated file. Click Save and choose the location to
place the generated file.
Note: If you have specified an inclusion criteria within the TeamMateIntegration.properties file,
an additional button will be displayed to export TeamMate Tests. Clicking this button will
ignore any selections you have made from the process list and export only those objects (within
the current scope) that match the criteria you specifed in the properties file.
Importing the Data Into TeamMate

Please refer to your TeamMate documentation on importing external data files.
Exporting Data to TeamMate 176
Troubleshooting the Export Process

Some or all of the selected processes are not being exported.
If you have selected a process that does not contain Risks, Controls, or Tests, that
Process will not be exported.
If you have turned on the option to export Tests without Test Results, some of the
selected processes may already have Test Results associated with their Tests and
therefore would not be exported.
Make sure you are clicking the Export button, and not the Export TeamMate Tests
button. Clicking the Export TeamMate Tests button will ignore the selected processes
and compare all processes in the selected business entities with the property criteria
specified in the properties file.
Importing Data From TeamMate 177
Importing Data From TeamMate

How Importing Data Works
After the auditing team has finished testing the controls exported from SOX Express, the
collected data must be exported from TeamMate and re-imported back into SOX Express.
The main steps for importing data from TeamMate are:
Exporting the Data From TeamMate

Transforming the XML File
Importing the TeamMate Data
Exporting the Data From TeamMate

Directions for exporting the TeamMate data can be found in the TeamMate documentation.
When you export the necessary data from TeamMate, be sure to select the Export to SOX
Express option.
Transforming the XML File

Once you have generated the XML file containing the exported TeamMate data, you must
transform the XML into the OP XML format. SOX Express provides a command to perform this
transformation - teammatesox.
To transform the TeamMate XML file, do the following:
1.
2.
3.
4.
Copy the TeamMate output file to a directory on the application server.

Open a command window on the application server.
Change directories to the location of the TeamMate XML file.
Type the following on a single line:
teammatesox <input_file> TM_OP_XSL.xsl teammate_data-op-config.xml
where:
<input_file> is the name of the XML file you generated from TeamMate
The name of the output file (teammate_data-op-config.xml) can be customized if you
desire, but the filename must end in -op-config.xml. This is required because the
import tool for SOX Express expects this filename convention.
Importing the TeamMate Data

After the transformation is complete, you must import the generated file into SOX Express.
To import the transformed file:
1.
2.
Open a command window on the application server, if one is not already open.
Go to the WebLogic Server OpenpagesDomain directory and run the following
command on a single line:
ObjectManager load config SOXAdministrator <password>
<config-folder-path> <prefix>
Where:
<password> is the password to the SOXAdministrator account.
<config-folder-path> is the folder where the input files for the load process are to be
found (if not specified, they will be loaded from the current directory).
Importing Data From TeamMate 178
<prefix> is the prefix of the files used by the load process. For example, if the
generated filename of the TeamMate import file is teammate_data-op-config.xml, the
<prefix> value would be teammate_data (without the quotes).
3.
After ObjectManager has completed the command, close the command window.
Displaying the TeamMate Properties

When the TeamMate data is imported back into the SOX Express system, it contains some
additional properties added by TeamMate. These properties will not display in the SOX Express
user interface until definitions for the properties are added to the configTileDefinitions.xml file.
The new fields are:
Compliance
Object Type
Test (SOXTest)
Bundle Name
SOXTestTeammate
Property Name
Teammate Test
Performer
Teammate Test
Reviewer
Test Result
(SOXTestResult)
SOXTestResultTeammate
Teammate Project ID
Teammate Test Result
Conclusion
Teammate Date
Performed
Teammate Date
Reviewed
Issue (SOXIssue)
SOXIssueTeammate
Teammate Issue
Impact
Task (SOXTask)
SOXTaskTeammate
Teammate Action Item

Status
For each of these fields, you must complete the following procedure to display the new field in
SOX Express:
The next step in the process of enabling your new property is to edit the
configTileDefinitions.xml file so that your new property is recognized by the SOX Express
application.
To activate the new property:
1.

2.

changes.
3.
example, if you are modifying a test, the string would be test.prop.body.
4.
5.
Remove the comment tags () from the object definition if this is the
first time you are modifying the object.
Modify the <putlist> tag to include the definition for the new property, as in the
example below:
<add value="test.property.isEffective"/>
<add value="test.property.newProp"/>
</putList>
The order of the property definitions controls the order in which they will be listed on
the object Details page and in the Add and Edit pages. Insert the new property
definition into the spot where you want the property to be listed.
Make sure the name for the new property definition (i.e. test.property.newProp in this
example) does not inadvertently match another property definition already defined for
the object.
Note: When modifying the Business Entity definition (busentity.prop.body), you must
remove the three sample property definition lines from the sample business entity
definition. The lines to be removed are:
<add value="customer.busentity.property.newProp"/>
<add value="customer.entity.property.ExecutiveOwner"/>
<add value="customer.entity.property.PrimaryOwner"/>
6.
Add the definition tag for the new property after the <definition> end tag containing
the <putlist> tag, using the format of the example below. A sample definition tag can
also be found in the XML file. Portions of the example in bold text should be replaced
with text specific to your property.
<definition>
<add value="test.property.isEffective"/>
<add value="test.property.newProp"/>
</putList>
</definition>
<definition name="test.property.newProp">
<put name="property.name" value="AddedProperty"/>
</definition>
The string test.property.newProp should be replaced with the property name as defined
in the property list (e.g. test.property.teammateTestPerformer). The string
TestBundle should be replaced with the name of your new property bundle (e.g.
SOXTestTeammate). The string AddedProperty should be replaced with the name of
the new property you are adding (e.g. Teammate Test Performer.
After modification, the new property definition should look like this:
<definition name="test.property.TeammateTestPerformer">
<put name="bundle.name" value="SOXTestTeammate"/>
<put name="property.name" value="Teammate Test Performer"/>
</definition>
Make sure you match the spelling and case of the property bundle and property name
exactly. Use the values in the above table to determine the values you should be using
in your new definitions.
7.

SOX Adminis Manual

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SOX Adminis Manual

Hochgeladen von

Copyright:

Verfügbare Formate

Sarbanes-Oxley

What is Sarbanes-Oxley Express? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Administering SOX Express

Using Application Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Setting Up LDAP User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 27

Configuring Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Working with Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Limiting the Report Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Managing Reporting Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Resetting Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Starting Jobs from SOX Express Objects . . . . . . . . . . . . . . . . . . . . . . . 59

Configuring SOX Express

Using the Restore Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Managing Signatures and Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Enabling Workflows for SOX Express Objects . . . . . . . . . . . . . . . . . . . . 71

Changing the Database Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Modifying SOX Express Behavior

Modifying Compliance Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Overview of Modifying Compliance Objects . . . . . . . . . . . . . . . .

Additional Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Using Netegrity SiteMinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

The Notification Manager

Exploring the Notification Reports . . . . . . . . . . . .

Step Three: Triggering the Notification . . . . . . . . . . . . . . . . . . . . . . . . 129

The SOX Express Reporting Schema

Master Relationships Table . . .

Integrating with TeamMate

Importing Data From TeamMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

This Administration Guide provides information and instructions for

What is the Sarbanes-Oxley Act of 2002? 2

What is the Sarbanes-Oxley Act of 2002?

What is Section 302?

What is Section 404?

What is Sarbanes-Oxley Express? 3

What is Sarbanes-Oxley Express?

How Can Sarbanes-Oxley Express Help Me?

Collaborative Task Management

Automated Reporting Processes

Internal Controls Documentation Repository

What is Internal Controls Documentation?

Administering Users and Groups on page 6

Administering Users and Groups 6

Administering Users and Groups

About User Names and Passwords

The maximum length of a user name is 32 characters.

Exclamation point or bang

When creating passwords, the following rule applies:

The maximum length of a password is 32 characters.

Creating a New SOX Express User

Administering SOX Express

Administering Users and Groups 7

Modifying an Existing User Account

Disabling a User Account

Re-enabling a SOX Express User

Administering SOX Express

Administering Users and Groups 8

Associating an Existing User with a Group

Disassociating a User from a Group

Administering SOX Express

Administering Users and Groups 9

Tip: Finding Users Quickly

Administering SOX Express

Using Application Permissions 10

Using Application Permissions