Below are some requested clarification points around functional access capabilities. The ones with reversed backgrounds are the ones requiring clarification.
Freeze Capabilities
Standard
| Interpretation
| Query
|
|---|
| Extend or suspend (freeze) the retention period of record folders or records beyond their scheduled disposition. [C2.2.7.4.1.] | In the implementation a freeze will require the user to input a freeze date, although this may be indefinite. The user will also be required to enter a reason for freezing. | OK |
| Unfreeze records or record folders. [C2.2.7.4.1.] | This is simply the ability to unfreeze previously frozen items. | OK. |
| Search, update, and view the reasons for freezing a record or record folder. [C2.2.7.4.4.] | A user this capability can search for frozen records based on the text of the freeze reason and view and update the reason. | OK. |
| Enter reasons for freezing a record or record folder. [C2.2.7.4.1.] | This is incorporated as part of the freeze process. | I can't envisage when a user would require this functional access on its own, as this capability is covered by the ones above. |
| Ensure database and business rules are in place to support freezing/unfreezing records and record folders. [C2.2.7.4.1., C2.2.7.4.2., C2.2.7.4.3. C2.2.7.4.4.] | This capability is incorporated as part of the freeze capabilities defined above. | I can't envisage what this functional access does over and above the other functional access capabilities related to freeze. |
Transfer and Destroy Capabilities
Standard
| Interpretation
| Query
|
|---|
| Delete records and/or related metadata after successful transfer has been confirmed. [C2.2.7.5.4.] | Transfers always have to be confirmed as being successful, prior to destruction. | OK |
| Confirm the delete command before the destruction operation is executed. [C2.2.7.6.2.] | This is incorporated as part of the delete after a transfer. | In our implementation confirmation of the delete will be mandatory, however this functional access requirement almost suggests that you could setup the system to have the delete after transfer only work when two people are present, one with 'Delete records' capability and the other with the 'Confirm delete' capability. I don't think that this is what is intended but just wanted to check. |
| Access record destruction commands. [C2.2.7.6.5.] | We are taking this to mean a destroy of a record outside of its disposition instructions. | Therefore somebody with this capability would be able to destroy records even if they have not reached the destroy phase of their disposal schedule, is this a correct assumption. |
Records Management Roles
The four roles that are included in the DoD 5015.02-STD compliance test cases are contrived. For example in DISA we have different roles.
Role
| Responsibilities
|
|---|
| Agency Records Officer | The Agency Records Officer (ARO) oversees the Agency records management program and provides guidance on adequate and proper recordkeeping. |
| Records Management Coordinator | Each Directorate has a Records Management Coordinator (RMC) coordinating its records management program. |
| Records Custodian | Each Division and Branch has a responsibilities for their own office set of records. A records custodian must keep the RMC informed of any issues regarding the records in their custody. |
| Information Resource Managers and System Managers | Information resource managers and system managers must ensure that information systems are designed with consideration for recordkeeping requirements, and that information systems intended to carry out electronic records management comply with federal and DISA requirements. |
| Agency Staff | All Agency staff must follow DISA's records management policies, procedures and guidance. |
If we were to do an agency wide roll out of a solution, the Records Custodian would have to work with the local IRM/SM people to determine access for the other members of the local staff. I can imagine that each portfolio would have a 'local records officer' type of role and would coordinate with the Records Custodian, but would not work for him/her. And we would have the typical users, initially probably the administrative assistants (who down the road would likely need some minor editing permissions to clean up the messes made by our test officers.)
The point is that the tool must have the functional permissions as a sufficiently refined level that they can be assigned with as little assumed 'bundling' or 'dependencies' as possible. Janamg 18:03, 2 June 2009 (BST)
Capabilities and Access Rights
I understand the answer and more importantly the direction of travel. This helps me then with another decision we need to make regarding functional access. Some capabilities have a 'they have filing rights to' appended to them, we are extending this further to mean 'Access Rights Required' and will add these to some of the other capabilities.
As an example 'Extend or suspend (freeze) the retention period of record folders or records beyond their scheduled disposition. [C2.2.7.4.1.]' will also require the user to have the correct access permissions to that part of the fileplan.
This will give you a great deal of flexibility and if necessary you can use coarse grained permissions to allow an individual to Freeze records anywhere in the fileplan. Hope this is OK.
Rolling your own Roles
In a perfect world, a permissioned person would be able to group fine grained permissions into role packets which could then be combined to define organizational roles. For example to file something, you need some sort of create object(s) capability and some sort of editing/change capability on some types of object(s). A reader would need to be able to find things and save searches and perhaps relate some personal 'sticky notes,' but not change the core object. So a typical user role would combine the filer and searcher roles (unless create assumes read somehow.) I don't know how fine grained it can get. Seems silly to say that someone can create something in an area that they later cannot find. (Side note...do you blip?)
