Military reference books and manuals (2009-2023, Volume 1) - page 16
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
Once aware of the system, the RO will work with the System Owner to determine whe ther or not
the system will contain records. If not, the process stops and the RO will make an entry into the
RMD database with a basic description of the system along with the fact that it will not contain
records.
If the system will contain records, the System Owner must determine the system approach for
meeting the ERK criteria (i.e., Integration, Direct Export, Integral, Deferred, as described in
Section 1.4). RMD personnel are available to advise the System Owner on the benefits and
drawbacks of each approach. The System Owner may also access the RMD Web page on the
FBI intranet to review ERK criteria and ERKC guidance documents. Once the System Owner
has determined an approach, he or she will document that approach in a written notice to RMD.
Table 2-1 illustrates the steps to the Definition phase, including who is responsible for each
action and what products (if any) must be produced at each step by each party (i.e., Records
Officer or System Owner).
Table 2-1. ERKC Definition Phase - New System
New System ERKC Definition Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
1. Review available system
System logged into RMD
documentation (e.g.,
ERKC tracking database
Exhibit 300s, Exhibit 53s,
System Security Plans,
Application Architectures)
to identify new systems.
2. Meet with System Owner
Description of system for
2. Meet with RO to determine
to determine whether
inclusion within RMD
whether system will contain
system will contain
database, and indication of
records. If NO, STOP; if
records. If NO, return to
whether system contains
YES, proceed to Step 3.
step 1; if YES proceed to
records
Step 3.
3. Assist System Owner to
Logged indication of planned
3. Establish ERK approach.
Written notice to RO of ERK
establish ERK approach
ERK approach
approach to be taken
(as requested by System
Owner).
2.2.2 Verification Phase
The Verification Phase follows the Definition Phase and its purpose is to ensure inclusion of
ERK criteria into system requirements specifications and test plans that will enable the system to
meet ERK criteria when it undergoes subsequent integration and acceptance testing. Table 2-2
illustrates the steps and products associated with this phase. The ERK Assessment Criteria,
along with sample tests and expected results, are provided in Appendix C.
For Official Use Only
2-4
Version 1.0
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
Table 2-2. ERKC Verification Phase - New System
New System ERKC Verification Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
4. Assist System Owner to
4. Understand ERK criteria
Requirements specifications
understand ERK criteria
sufficiently to develop
addressing ERK criteria
(as requested by System
system requirements.
Owner).
5. Assist System Owner to
Comments and
5. Develop System
System Requirements
incorporate necessary ERK
recommendations on System
Requirements
documentation addressing
criteria into System
Requirements documentation
documentation,
ERK criteria
Requirements docu-
(on request of System
incorporating necessary
mentation (as requested by
Owner)
ERK criteria.
System Owner).
6. Assist System Owner to
Comments and
6. Develop the Integration
Test Plan
incorporate necessary ERK
recommendations on Test
Test Plan, incorporating
criteria into Test Plan (as
Plan (on request of System
necessary ERK criteria.
requested by System
Owner)
Owner).
2.2.3 Validation Phase
Following development of the Test Plan, the Validation phase begins. During this phase, the
System Owner will conduct integration/acceptance testing in accordance with the Test Plan
developed during the ‘Develop and Test’ phase of the SDLC. The RO will review the results of
that testing to validate compliance with ERK criteria. The RO will then produce a system
certification report that identifies all areas of non-compliance. A template for development of an
ERK System Certification Report is presented in Appendix J. The RO may need to conduct a
risk analysis and the System Owner may need to prepare a risk mitigation plan (also know as an
action plan) if full compliance is not evidenced. Information on conducting a risk analysis is
located in Appendix F. Table
2-3 illustrates the steps and products associated with the
Validation phase.
Table 2-3. ERKC Validation Phase - New System
New System ERKC Validation Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
7. Support integration/
Comments and
7. Conduct the integration/
Test Results
acceptance testing (as
recommendations on conduct
acceptance testing and
requested by the System
of integration/acceptance
document the results of the
Owner).
testing (as requested by the
test; provide a copy of the
System Owner).
results to the RO.
8. Review test results and
8. If YES, proceed to operate
determine whether all ERK
the system; go to Step 11
criteria have been met.
(Post Certification phase).
If YES, certify the system
by granting an ATO;
If YES, System Certification
If NO, proceed to step 9
proceed to Step 11 (Post
Report and ATO.
Certification phase).
If NO, System Certification
For Official Use Only
2-5
Version 1.0
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
New System ERKC Validation Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
If NO, proceed to Step 9.
Report.
9. Perform a Risk Analysis;
If YES, IATO.
9. If YES, operate system
If YES, written acknowledge-
determine whether
under terms of IATO;
ment of terms of IATO (to be
existing risks are
proceed to Step 11 (Post
provided to RO).
acceptable.
Certification phase).
If YES, issue an IATO;
proceed to Step 11 (Post
Certification phase).
If NO, request preparation of
If NO, prepare Risk
If NO, Risk Mitigation Plan.
If NO, direct System Owner
Risk Mitigation Plan.
Mitigation Plan; proceed
to prepare a Risk
to next step.
Mitigation Plan; proceed
to next step.
10. Examine Risk Mitigation
Determination on feasibility of
10. If YES, proceed to next
If YES, written
Plan and determine its
Risk Mitigation Plan.
step.
acknowledgement of terms of
feasibility. If plan is
If YES, IATO
IATO (to be provided to RO).
feasible (i.e., YES), pro-
ceed to next step. If plan
If NO, NATO.
If NO, revise mitigation plan.
is not feasible (i.e., NO),
issue NATO; STOP.
2.2.4 Post Certification Phase
There are two primary purposes of the Post Certification phase. The first is to enable the RO to
determine whether the terms of any IATO should be extended, or whether the IATO should be
changed to an ATO, or to a NATO. The second is to perform routine, periodic (every three
years) reviews of the status of systems granted ATOs to ensure that such systems continue to
meet all ERK criteria.
Each IATO issued by the RO will have certain terms and conditions associated with it. For
example, the IATO may authorize operations of a system (not fully compliant with electronic
recordkeeping requirements) for a specified period of time (e.g., 12 months). The RO may issue
such an IATO to accommodate the development of a system following a spiral development
process in which all of the required electronic recordkeeping criteria are not expected to be
satisfied until the second release. Or, an IATO may be intended to accommodate the
development and implementation of a system put in place to meet emergency operational needs
(e.g., the tracking system used in response to the Washington metropolitan-area sniping incident
in the fall of 2003). Similarly, an IATO may authorize the operation of a system in a restricted
operational environment (e.g., on a separate local area network not connected to the FBI intranet)
to serve as a proof of concept before implementing its fully ERK-compliant counterpart on a
broader scale.
Regardless of the terms and conditions associated with the IATO, the intent of the Post
Certification phase is to examine the operation of the system covered by the IATO and determine
the next appropriate step to be taken. In the above hypothetical example of a system following a
spiral development methodology, with the implementation of the second release, the appropriate
action may be to convert the IATO to an ATO. In the case of a system developed for emergency
operational needs, the appropriate action may be to disallow continued operations (e.g., the
For Official Use Only
2-6
Version 1.0
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
emergency is over) and require all of the records created within the system to be transferred to an
approved RMA.
With respect to systems granted ATOs, the RO must review the operations of such systems every
three years to ensure continuing compliance with ERK criteria. Once granted an ATO, a system
may undergo changes (e.g., new functionality) that could cause the system to no longer satisfy
the ERK criteria. In such cases, the RO may require further modifications to the system in order
to accommodate these ERK criteria.
Table 2-4 illustrates the steps and products associated with the Post Certification phase.
Table 2-4. ERKC Post Certification Phase - New System
New System ERKC Post Certification Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
11. Monitor ATO and IATO
11. Operate system under
expiration dates.
terms and conditions of
the granted ATO or IATO.
12 Notify System Owner of
Re-certification Notice
12. Provide relevant
If ATO, provide requirements
re-certification
documentation
specifications for new
functionality (since last ERK
certification)
If IATO, provide evidence
(requirements
specification/test results) of
compliance with conditions of
IATO.
13. Review documentation
13. Support RO review of
and determine whether all
documentation.
ERK criteria have been
met.
If YES, certify the system
If YES, System Certification
If YES, continue to operate
by granting an ATO;
Report and ATO.
the system; go to Step 11
proceed to Step 11 (Post
(Post Certification phase).
Certification phase).
If NO, System Certification
If NO, proceed to Step 14.
Report., proceed to step 14.
If NO, proceed to step 14
14. Perform a Risk Analysis;
If YES, IATO.
14. If YES, operate system
If YES, written acknowledge-
determine whether
under terms of IATO;
ment of terms of IATO (to be
existing risks are
proceed to Step 11 (Post
provided to RO).
acceptable.
Certification phase).
If YES, issue an IATO;
proceed to Step 11 (Post
Certification phase).
If NO, request preparation of
If NO, prepare Risk
If NO, Risk Mitigation Plan.
If NO, direct System Owner
Risk Mitigation Plan.
Mitigation Plan; proceed
to prepare a Risk
to next step.
Mitigation Plan; proceed
to next step.
For Official Use Only
2-7
Version 1.0
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
New System ERKC Post Certification Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
15. Examine Risk Mitigation
Determination on feasibility of
15. Review mitigation plan
If YES, written
Plan and determine its
Risk Mitigation Plan.
with RO
acknowledgement of terms of
feasibility
If YES, IATO
IATO (to be provided to RO).
If NO, NATO.
If NO, revise mitigation plan.
2.3 ERKC Process for Legacy Systems
The ERKC process for legacy systems requires that System Owners and the RO undertake
activities in only the last two phases of the ERKC lifecycle because such systems have already
been developed and undergone integration and acceptance testing (most likely without regard to
electronic recordkeeping requirements). The sections below describe the associated activities
and provide a simplified “checklist” approach that outlines who does what and who must
produce certain written products to support the certification process.
(Appendix E provides a
graphical process- flow model of the ERKC activities for legacy systems.) Because integration
and acceptance testing will have already occurred for legacy systems, it may be necessary to
develop and cond uct a special certification test (validation by demonstration) if the RO is unable
to determine from a review of existing system documentation4 whether the system complies with
ERK criteria.
2.3.1 Validation Phase
The purpose of the Validation phase for legacy systems is to determine whether the system
satisfies the ERK Assessment Criteria, presented in Appendix C. The RO will attempt to
ascertain this fact by reviewing various documents associated with the system. If sufficient
information is not available, the RO will request the conduct of a specially focused certification
test.
The RO will initiate the ERKC process whenever he or she becomes aware of a legacy system.
Triggers include Exhibit 300s and 53s, revisions to system security plans, and updates to
application architecture documents. The RO will work with the System Owner to determine
whether the system contains records. If the system does not contain records, no further action by
the System Owner is required
- the RO documents this fact in the RMD database discussed
earlier in section 2.2.1.
If the system does contain records, the RO will attempt to determine whether the system meets
all necessary ERK criteria by reviewing the results of the system’s integration/acceptance
testing. If an appropriate determination cannot be made from these test results, the RO will
request additional documentation (e.g., user’s manuals, system administration manuals). If the
RO still cannot determine whether the system satisfies the needed ERK criteria, the RO will
direct the System Owner to develop and conduct a special certification test for the system. From
this point on, the System Owner and the RO will follow the same process described in Section
4 Existing documentation may include, but is not limited to, test plans, system design documents, requirements
specifications, user’s manuals and system administration manuals.
For Official Use Only
2-8
Version 1.0
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
2.2.3 for the Validation phase for a new system. As noted in Section 2.2.3, this process may
require the RO to conduct a risk analysis and the System Owner to prepare a risk mitigation plan.
Table 2-5 illustrates the steps and products associated with the Validation phase for a legacy
system.
Table 2-5. ERKC Validation Phase - Legacy System
Legacy System ERKC Validation Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
1. Review available system
System logged into RMD
documentation (e.g.,
ERKC tracking database
Exhibit 300s, Exhibit 53s,
System Security Plans,
Application Architectures)
to identify legacy systems.
2. Meet with System Owner
Description of system for
2. Meet with RO to determine
to determine whether
inclusion within RMD
whether system contains
system contains records.
database, and indication of
records.
whether system contains
If YES proceed to Step 3.
records
If YES, proceed to Step 3.
3. Request Requirements
Request for System
3. Provide System
System documentation.
Specifications, Test Plans,
documentation.
Documentation (as
and test results from
available)
system
integration/acceptance
testing.
4. Review System
System Certification Report.
Documentation to
If YES, ATO
determine whether ERK
If NO, go to Step 5.
criteria are being met
5. If documentation is
Updated System Certification
5. Demonstrate relevant
System demonstration.
insufficient to evidence
Report
system functionality in
compliance, validate ERK
support of ERKC
criteria by demonstration
evaluation.
6. Review System
6. If YES, continue to operate
Certification Report and
If YES, ATO.
the system; go to Step 11
determine whether all ERK
(Post Certification phase).
criteria have been met.
If NO, proceed to next step
If NO, proceed to Step 14.
If NO, proceed to next step.
7. Perform a Risk Analysis;
7. If YES, operate system
If YES, written acknowledge-
determine whether
ment of terms of ATO (to be
existing risks are
provided to RO).
acceptable.
If YES, issue an ATO;
If YES, ATO.
If NO, direct System Owner
If NO, request preparation of
If NO, prepare Risk Mitigation
If NO, Risk Mitigation Plan.
to prepare a Risk
Risk Mitigation Plan.
Plan; proceed to next
Mitigation Plan; proceed
step.
to next step.
For Official Use Only
2-9
Version 1.0
FBI Electronic Recordkeeping
Electronic Recordkeeping
Certification Manual
Certification Process
Legacy System ERKC Validation Phase: Activities and Products
Records Officer
System Owner
Activity
Product
Activity
Product
8. Examine Risk Mitigation
Determination on feasibility of
8. Review mitigation plan with
If YES, written
Plan and determine its
Risk Mitigation Plan.
RO
acknowledgement of terms of
feasibility
If YES, IATO
IATO (to be provided to RO).
If NO, NATO.
If NO, revise mitigation plan.
2.3.2 Post Certification Phase
The purpose of the Post Certification phase for a legacy system is twofold. First, it is to enable
the RO to determine whether the terms of any IATO should be extended or whether the IATO
should be changed to an ATO or to a NATO. Second, it is to enable the RO to perform routine,
periodic (every three years) reviews of the status of systems granted ATOs to ensure that such
systems continue to meet all ERK criteria.
IATOs for legacy systems will have certain terms and conditions associated with them. For
example, an IATO may authorize the continued operations of a non-ERK-compliant system for a
specified period of time (e.g., 12 months) because that system will be retired or replaced with an
ERK-compliant system within that period of time and the costs of retrofitting the non-compliant
system are deemed excessive relative to the risks associated with its continued as-is operations.
Similarly, the RO may issue an IATO for a legacy system because there is a planned upgrade to
the system that will make it ERK-compliant within a specified period of time. Lastly, the RO
may issue an IATO for a legacy system because it was developed and implemented for
emergency purposes and the emergency situation still exists. The process for post-certification
of legacy systems, however, is identical to the post-certification process described for new
systems. This process is described in detail in Table 2-4.
v v v
For Official Use Only
2-10
Version 1.0
FBI Electronic Recordkeeping
Roles and Responsibilities
Certification Manual
Section Three—Roles and Responsibilities
his section summarizes the primary roles and responsibilities of the two principal
T
participants in the electronic recordkeeping certification
(ERKC) process. Section 3.1
highlights the responsibilities of the Records Officer
(RO). Section
3.2 summarizes the
responsibilities of the System Owner.
3.1 Records Officer ERKC Responsibilities
The principal role of the RO is to determine whether FBI IT systems contain records. If so, the
RO certifies whether the system meets the FBI criteria for an ERK system. In performing ERKC
activities, the Records Officer shall execute the following responsibilities:
§
Develop, publish, and maintain, on the RMD page of the FBI intranet, ERK criteria
associated with the four defined approaches to meeting ERK criteria (i.e., Integration,
Direct Export, Integral, Deferred).
§
Determine, in consultation with System Owners, whether a system contains records
(legacy systems) or will contain records once implemented (new systems).
§
As requested by System Owners, provide advice and guidance to System Owners when
they are selecting their prefe rred approach to meeting ERK criteria.
§
As requested by System Owners, provide advice and guidance on the ERK certification
content of System Owner-developed Test Plans.
§
As requested by System Owners, provide assistance on the conduct of the ERK
certification portions of Test Plans.
§
Review and evaluate the results of Test Plans, or other relevant system documentation,
from an ERK certification perspective, and report results of the ERK certification
evaluation.
§
For legacy systems, determine whether validatio n by demonstration is required, and notify
System Owners of the requirement.
§
Perform risk analyses, as needed, for systems to determine whether the risks posed by
systems not meeting all ERK criteria are acceptable risks.
§
Direct System Owners to prepare Risk Mitigation Plans for systems not meeting all ERK
requirements that pose unacceptable risks; determine the feasibility of successfully exe-
cuting such Risk Mitigation Plans and so notify System Owners.
§
Determine the appropriate certification [i.e., Approval to Operate (ATO), Interim Approval
to Operate (IATO), and No Approval to Operate (NATO)] for each system that comes
under his or her cognizance.
§
Review systems operating under the terms and conditions of an IATO and determine
whether to issue an ATO, extend the terms of the IATO, or issue a NATO.
§
Review systems operating under ATOs every three years and determine whether to grant
re-certification for such systems (new ATO), issue an IATO, or issue a NATO.
For Official Use Only
3-1
Version 1.0
FBI Electronic Recordkeeping
Roles and Responsibilities
Certification Manual
3.2 System Owner ERKC Responsibilities
The System Owner’s role is to ensure that FBI IT systems for which they are responsible meet
the FBI ERK criteria. In operating their systems and participating in ERKC activities, System
Owners shall execute the following responsibilities:
§
Notify the RO of all planned new systems and existing legacy systems.
§
Meet with the RO, when requested, to help determine whether systems contain records.
§
Establish the appropriate ERK approach for each system owned or operated by the System
Owner.
§
For new systems, develop and incorporate the appropriate ERK criteria into the system
requirements specifications and integration/acceptance Test Plans (in consultation with the
RO, if so desired).
§
Conduct system integration/acceptance testing according to Test Plans containing appro-
priate ERK criteria.
§
Provide standard system documentation
(e.g., user’s manuals, system administration
manuals, system design documents), as requested by the RO, to support the ERKC process.
§
Provide the results of (1) integration/acceptance tests and, as appropriate, (2) ERKC tests
to the RO.
§
When requested by the RO, develop Risk Mitigation Plans for systems.
§
Notify the RO of planned changes to any system operating under an ATO that might
adversely affect the ERK certification of that system.
§
Comply with the terms and conditions of the appropriate certification (i.e., ATO, IATO,
and NATO) for each system that is operated.
§
Cooperate with the RO in the review and re-certification activities (every three years) for
each system granted an ATO.
v v v
For Official Use Only
3-2
Version 1.0
FBI Electronic Recordkeeping
Appendix A
Certification Manual
References
Appendix A—References
Basic Functional Requirements for Electronic Recordkeeping (ERK) for Automated Systems/
Applications in the FBI, FBI, draft of March 3, 2003
Design Criteria Standards for Electronic Records Management Software Applications, DoD
5015.2-STD, June 19, 2002
FBI Certification and Accreditation Handbook, FBI, Version 1.1, July 31, 2003
FBI Enterprise Records Management Application: High-Level Functional Requirements, FBI,
66F-HQ-C14032470-5, Revised February 2003
Framework for Integration of Electronic Document Management and Electronic Records
Management Systems, ANSI/AIIM/ARMA TR 48-200X Technical Report for Information and
Image Management, expected publish date June 2004
Management of Federal Information Resources, OMB Circular A-130, November 28, 2000
Program Management Office Functional Overview, PMO-PLN-001, Version 1.0, FBI, June
2003
Records Management Division Delegation of Authority to the Agency Records Officer, FBI, 66F-
HQ-A1358157-32, April 29, 2002
U.S. National Archives and Records Administration (NARA) Fast Track Project,
36 CFR § 1220 to 1238 (Records Management).
44 U.S.C.
§
29
(Records Management by the Archivist of the United States and the
Administrator of General Services).
44 U.S.C. § 31 (Records Management by Federal Agencies).
v v v
For Official Use Only
A-1
Version 1.0
FBI Electronic Recordkeeping
Appendix B
Certification Manual
Glossary
Appendix B—Glossary
Acronyms
Abbreviation
Meaning
ATO
Approval to operate
C&A
Certification and Accreditation
CFR
Code of Federal Regulations
CPIC
Capital Planning and Investment Control
DoD
Department of Defense
EA
Enterprise Architecture
ERK
Electronic recordkeeping
ERKC
Electronic recordkeeping certification
FBI
Federal Bureau of Investigation
IATO
Interim approval to operate
ID
Identification (as in User ID)
IDW
Investigative Data Warehouse
IRM
Information resource management
IS
Information system
IT
Information technology
KM
Knowledge management
NARA
National Archives and Records Administration
NATO
No approval to operate
OMB
Office of Management and Budget
RM
Records management
RMA
Records management application
RMD
Records Management Division
RMP
Risk mitigation plan
RO
Records Officer
SDLC
System Development Life Cycle
U.S.C.
United States code
VCF
Virtual Case File
For Official Use Only
B-1
Version 1.0
FBI Electronic Recordkeeping
Appendix B
Certification Manual
Glossary
Terms
Term
Definition
Approval to operate
Certification to operate a system on a “permanent” basis (in the
absence of subsequent modifications to the system); granted by
the Records Officer. Each ATO is good for a period of three
years and the System Owner must seek re-certification for each
system operating under an ATO within the 3-year window that
begins upon the granting of an ATO for that system.
Category
A category is a records series, or a group of records with similar
characteristics assigned to a particular records retention
schedule and generally handled as a unit for disposition
purposes. In many RMAs, a category is a file folder icon in
which records are assigned.
Disposition instructions
Those actions taken regarding Federal records after they are no
longer required to conduct current Agency business. These
actions include: 1) transfer of records to Agency storage
facilities or Federal Record Centers (FRCs); 2) transfer of
records from one Federal Agenc y to another; 3) transfer of
permanent records to the National Archives; 4) disposal of
temporary records, usually by destruction.
Exact match search
Exact- match searches return data that include the exact search
string; also known as “on-the-nose” search.
File Plan
A file plan is a document containing the identifying number,
title or description and disposition authority of files held or used
in an office.
Global change
A global change is an automatic search-and-replace feature.
Global changes are performed when one change needs to be
made to a number of records. By doing a global change, the
new data is keystroked once.
Investigative Data Warehouse
A portal to various FBI databases and documents that includes a
workflow process and search capabilities for the purpose of
discovering knowledge.
Interim approval to operate
Certification to operate a system for a temporary period of time
and subject to specified conditions; granted by the Records
Officer.
Metadata
Metadata is structured data about data; it is a term that describes
or specifies characteristics that need to be known about data in
order to build information resources such as ERK systems and
support records creators and users.
Proximity searching
Proximity or adjacency searches return data that include search
strings within a certain “distance” of other strings, e.g., when
the word “fire” is within 50 characters of “explosion.”
For Official Use Only
B-2
Version 1.0
FBI Electronic Recordkeeping
Appendix B
Certification Manual
Glossary
Terms
Record
Documentation of the organization, functions, policies,
decisions, procedures, and essential transactions of the FBI.
Risk analysis
The process performed by the RO to determine the acceptability
of the risks posed by a system that does not meet all of the
required ERK criteria.
Records Officer
The designated individual responsible for reviewing the ERK
capabilities of systems (both legacy and new) and determining
whether to grant the System Owner permission to operate that
system from a recordkeeping perspective.
Relevance ranking
Relevance ranking is a system mechanism that determines the
degree to which the retrieved data are relevant to the search.
Risk mitigation plan
A plan developed by the System Owner that spells out a
proposed approach to alleviate the risks posed by a system that
does not meet all ERK criteria.
Sealed Records
Sealed records are those that have been redacted, and have an
identifying border burned into the document so that redacted
information may not be reverse engineered. Sealed documents
may not be unsealed.
Stop words
Stop words are extremely common words that a search engine
will not search for in order to save space or to speed up
searches. Examples include: "the," “it,” “and,” “a," “or,” etc.
System owner
The individual with responsibility for developing or operating
an FBI information or knowledge management system.
Unmet ERK criteria
A set of ERK criteria, determined by the RO, for a system
undergoing ERKC that the system fails to satisfy.
Virtual Case File
The electronic repository of case file records, which includes a
records management system operated by the FBI that meets FBI
records management requirements.
Vital Record
Vital records are those needed by agencies for continuity of
operations before, during, and after emergencies, and those
records needed to protect the legal and financial rights of the
Government and persons affected by Government activities.
Wildcard characters
Wildcard characters can be used in queries in place of unknown
characters and to search for multiple variations of a term. For
example, searching on “terror*” would retrieve data that include
“terror,” “terrorist,” “terrorism,” etc.
v v v
For Official Use Only
B-3
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Appendix C—ERK Assessment Criteria
Appendix C contains the ERK assessment criteria that have been established by the Records
Management Division for all FBI recordkeeping information systems. The criteria are the basis
for which new and existing systems are evaluated for electronic recordkeeping certification.
Each criterion is followed by one or more sample tests and expected results that can be used to
assist System Owners in developing test plans and to support the review of test results by
Records Officers. NOTE: The “user” refers to authorized users only. Different functions are
permitted to different groups of users - e.g., administrative functions to records managers,
retrieval functions to end- users, etc.
1.1 DECLARE RECORDS
Criterion 1.1.1:
The system designates specified information as records, either manually or
automatically.
Sample Test(s)
Expected Result(s)
Import a document into the system. Designate the
The document is marked/flagged as a record in its
document as a record.
metadata
Other documents in the system not designated as records
are not marked/flagged as records in their metadata.
Criterion 1.1.2:
The system assigns unique identifiers to records and their associated
metadata.5 The system prevents any modification of a record's unique
identifier, once it is defined.
Sample Test(s)
Expected Result(s)
Attempt to assign a common ID to two records.
The system generates a notification to the user that this
task is prohibited, and prevents assigning a common
ID to two distinct records.
Assign unique IDs to a set of records and their associated
Assigned IDs adhered to the records and their associated
metadata. Check whether the IDs adhered to the
metadata.
records and their associated metadata.
Attempt to modify or delete assigned IDs.
The system generates a notification to the user that this
task is prohibited, and prevents modifying and deleting
assigned IDs.
Criterion 1.1.3:
The system captures record metadata (FBI-designated and others)
automatically and reliably links metadata to the records.
Sample Test(s)
Expected Result(s)
For a record, retrieve each of the FBI-designated
Each FBI-designated metadata element is retrieved and
metadata elements.
populated with a valid entry.
1.2 CAPTURE RECORDS
Criterion 1.2.1:
The system imports records from sources outside the system (e.g., other
information systems, desktop applications, scanned documents, or e-mail)
along with all required associated metadata (e.g., records series, pre -existing
file plans6, or locations for physical records)
5 Metadata is structured data about data; it is a term that describes or specifies characteristics that need to be known
about data in order to build information resources such as ERK systems and support records creators and users.
6 A file plan is a document containing the identifying number, title or description and disposition authority of files
held or used in an office.
For Official Use Only
C-1
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Sample Test(s)
Expected Result(s)
Import a record and its associated metadata into the
The record and its associated metadata are successfully
system from a desktop management system.
imported into the system.
Criterion 1.2.2:
To provide records management control over the records without physically
transporting them to an RMA, the system links records to an external RMA.
Sample Test(s)
Expected Result(s)
Flag an entity in the system as a record and link it to the
The entity is identified in the system as a record and
relevant file classification in the RMA.
linked to the appropriate file classification and
disposition existing in the RMA; RMA treats the record
as a record.
1.3 MAINTAIN OR USE RECORDS
1.3.1 Record Organization
Criterion 1.3.1.1: The system accepts an FBI-specific scheme for organizing records. For
example, the system accepts FBI-specific records retention schedules and
organizes records according to the schedules.
Sample Test(s)
Expected Result(s)
Input an FBI-specific records retention schedule to the
FBI-specific records retention schedule is successfully
system.
input to the system.
Input information declared as records with pre-known
records retention schedule characteristics.
Process and output records according to the records
Information input to the system is output as records with
retention schedule.
correct records retention schedule characteristics.
Criterion 1.3.1.2: Users can select categories7 in which records are filed and assign records to
these categories.
Sample Test(s)
Expected Result(s)
Input a user-designated file plan category.
User-designated file plan category conflicting with FBI-
specific file plan is rejected.
User-designated file plan category not conflict with FBI-
specific file plan is accepted.
Assign records to the user-designated file plan category.
Records assigned to the user-designated file plan
category are contained within or linked to the
category.
Criterion 1.3.1.3: The system supports assignment of Vital Record8 indicators.
Sample Test(s)
Expected Result(s)
Input information that is a known Vital Record.
Designate the information as a Vital Record by assigning
Record is shown as Vital Record in its metadata.
a “yes” value to the Vital Record metadata element
Criterion 1.3.1.4: The system supports linking of related records (e.g., a redacted record with its
non-redacted counterpart, an original record with its revision, or an electronic
record with a paper antecedent9).
7 A category is a records series, or a group of records with similar characteristics assigned to a particular records
retention schedule and generally handled as a unit for disposition purposes. In many RMAs, a category is a file
folder icon in which records are assigned.
8 Vital records are those needed by agencies for continuity of operations before, during, and after emergencies, and
those records needed to protect the legal and financial rights of the Government and persons affected by
Government activities.
9 For example, an official correspondence may have been initiated on paper (paper antecedent), and the response
was an electronic reply (electronic record).
For Official Use Only
C-2
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Sample Test(s)
Expected Result(s)
Perform operation of linking records with other related
Record metadata carry information that designates other
records.
records to which they are linked.
Criterion 1.3.1.5: The system supports the capability for users to create and edit file plans,
including categories and sub -categories. The system prevents deletion of
non-empty folders.
Sample Test(s)
Expected Result(s)
Create a system file plan and a category and sub-
Categories and sub-categories are successful created,
category within the file plan.
edited and deleted in the system file plan.
Edit the file plan, category and sub-category.
Delete the file plan, category and sub-category.
Attempt to delete a category containing items.
The system generates a notification to the user that this
task is prohibited, and prevents deletion of the
category containing items.
Criterion 1.3.1.6: The system can assign a status to records to prevent destruction (i.e., the
system contains an indicator that includes an option to mark records as “do-
not-destroy,” which prevents records from being selected for destruction or
transfer according to records retention schedules).
Sample Test(s)
Expected Result(s)
Select the “do-not-destroy” status for a record that is
The “do-not-destroy” status is visible and enabled for the
identified for destruction according to the records
record.
retention schedule.
Attempt to identify the record for destruction while the
“do-not-destroy” status is selected.
Unsuccessful in identifying the record for destruction.
Criterion 1.3.1.7: The system supports global10 changes to metadata, file plans, and records
retention schedules.
Sample Test(s)
Expected Result(s)
Change the value of a metadata element from its current
All instances of the former value are changed to the new
value to another using a single keystroke.
value. No instances of the former value remain in
the selected metadata element.
Criterion 1.3.1.8: The system executes disposition11 instructions (e.g., moves a group of records
from active to inactive status or designates a group of records for destruction
or transfer).
Sample Test(s)
Expected Result(s)
Search the system for a set of records that are eligible for
System identifies and lists the set of records that are
disposition.
eligible for disposition
Use authorized user ID to approve and execute the
disposition instructions for the set of records
Use unauthorized user ID to attempt to approve and
The disposition instructions are successfully executed
execute the disposition instructions for the set of
under the authorized user ID.
records.
The system generates a notification to the user that this
task is prohibited, and prevents execution of
disposition instructions under the unauthorized user
ID.
10 A global change is an automatic search-and-replace feature. Global changes are performed when one change
needs to be made to a number of records. By doing a global change, the new data is keystroked once.
11 Those actions taken regarding Federal records after they are no longer required to conduct current Agency
business. These actions include: 1) transfer of records to Agency storage facilities or Federal Record Centers
(FRCs); 2) transfer of records from one Federal Agency to another; 3) transfer of permanent records to the National
Archives; 4) disposal of temporary records, usually by destruction.
For Official Use Only
C-3
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Criterion 1.3.1.9: For systems that manage physical records, the system specifies identifiers for
boxes, contents, locations, etc. In other words, the system stores metadata
for records not contained in the system and can identify records by physical
location (box number, location ID, etc.)
Sample Test(s)
Expected Result(s)
Enter in the system physical location metadata for a
Metadata for the physical record is accepted and stored
physical record.
in the system.
1.3 MAINTAIN OR USE RECORDS
1.3.2 Records Security
Criterion 1.3.2.1: The system prevents over-writing records. To comply with records
management guidelines, records are never edited, but new versions are
created and linked to the source.
Sample Test(s)
Expected Result(s)
Copy a record from the system to a document
Record copy is created and accessible in the document
management application.
management system.
Modify the record and attempt to re-file it in the system.
System prevents the modified record to overwrite the
original record. System prompts the user to file the
modified record as a new record.
Criterion 1.3.2.2: The system prevents deletion of indices, categories, and other 'pointers' to
records (i.e., maintains referential integrity).
Sample Test(s)
Expected Result(s)
User attempts to modify and/or delete indices and
Prohibited action will not happen. Indices or categories in
categories for a set of records.
use will not be deleted or modified.
Criterion 1.3.2.3: The system provides an automatic method to detect any alteration of records
or metadata.
Test(s)
Expected Result(s)
Verify in system design documentation that changes to
The system design documentation indicates that the
records or metadata can be automatically
system automatically determines (e.g., by
determined by the system.
checksums) when records or metadata have been
modified.
Using an authorized user ID, modify information
The system generates a notification of record
designated as a record.
modification.
Criterion 1.3.2.4: The system provides audit trails of all add, up date, deletion, and retrieval
activity.
Sample Test(s)
Expected Result(s)
Using an authorized user ID, create, access, edit and
The history and audit trail of the record indicates the
delete a record.
creation, access, modification and deletion of the
record. The history and audit trail are present and
accessible in the system.
Criterion 1.3.2.5: The system (or System Owner) maintains appropriate backup copies of
records and recordkeeping systems.
Sample Test(s)
Expected Result(s)
Verify that back-up procedures exist for the system.
The system follows its back-up procedures and has a
history of being backed up.
Criterion 1.3.2.6: The system is protected by adequate recovery/rollback and rebuild procedures
so that records may be recovered or restored following a system malfunction.
Sample Test(s)
Expected Result(s)
Verify that recovery/rollback and rebuild procedures exist
The system has recovery/rollback and rebuild procedures
for the system.
in place and they have been tested.
For Official Use Only
C-4
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
1.3 MAINTAIN OR USE RECORDS
1.3.3 Records Access
Criterion 1.3.3.1: The system controls access so that only authorized individuals are able to
retrieve, view, print, copy, or edit records or other entities (e.g., metadata, file
plan, etc.) in the recordkeeping system.
Sample Test(s)
Expected Result(s)
Designate a test set of user IDs; set access privileges to
retrieve, view, print, copy or edit a record:
Use an authorized user ID to retrieve, view, print, copy or
Record is able to be retrieved, viewed, printed copied and
edit a record.
edited.
Use an unauthorized user ID to attempt to retrieve, view,
The system generates a notification to the user these
print, copy or edit a record.
tasks are prohibited, and prevents the actions from
occurring.
Criterion 1.3.3.2: The system identifies individuals and groups of users and allows different
access privileges to be assigned to individuals or groups.
Sample Test(s)
Expected Result(s)
Designate two test sets of user IDs; give members of
each set different access privileges and restrictions.
For each set of user IDs, attempt actions that are both
Allowable actions will occur for each set of user IDs.
allowable and restricted based on the access
Prohibited actions will not occur for each set of user IDs.
privileges and restrictions set.
Criterion 1.3.3.3: The system maintains the integrity of redacted records and assures that
redacted material is not accessible on sealed12 records.
Sample Test(s)
Expected Result(s)
Retrieve a random sample of sealed records and verify
All redacted material in the sealed records is not
redacted material is not viewable.
viewable.
Attempt to reconstruct the redacted material.
The redacted material cannot be reconstructed.
1.3 MAINTAIN OR USE RECORDS
1.3.4 Records Retrieval
Criterion 1.3.4.1: The system ensures that all access privileges (permissions and restrictions)
are enforced on all retrievals.
Sample Test(s)
Expected Result(s)
Designate a test set of user IDs; set different records
retrieval access privileges for each of the IDs:
With each user ID, attempt both allowable and prohibited
Allowable retrievals will occur.
retrievals.
Prohibited retrievals will not occur.
Criterion 1.3.4.2: The system can retrieve records and their associated metadata and can
retrieve records based on defined links (e.g., between versions of the same
record or between the records in a particular case file).
Sample Test(s)
Expected Result(s)
Simultaneously retrieve both a record and its associated
The record and its associated metadata are retrieved in a
metadata.
single search.
Define a link among a record and its related records.
Links are defined, and the record and all its related
Then, search the system for this record and all its
records are retrieved in a single search.
related (linked) records.
12 Sealed records are those that have been redacted, and have an identifying border burned into the document so that
redacted information may not be reverse engineered. Sealed documents may not be unsealed.
For Official Use Only
C-5
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Criterion 1.3.4.3: The system provides a sufficiently powerful range of search features and
options, as needed to meet agency requirements. These might include:
searching on individual terms or a combination of terms, wildcard13 or exact-
match14 searching, proximity or adjacency15 searching, relevance ranking16 of
search results, use of stop words17, limits on maximum size of results set from
a search, query by image content, or others.
Sample Test(s)
Expected Result(s)
Conduct records searches by (a) searching on individual
All selected search functions are successfully completed.
terms, (b) searching on a combination of terms, (c)
Search results include only those that match the search
wildcard matching, (d) exact-matching, (e) proximity
criteria.
or adjacency searching, (f) excluding specified stop
words, (g) setting limits on the maximum size of the
results set, (h) searching ima ge content, and (i)
using other functions determined by System Owner
as necessary for the system.
Conduct a search that ranks the search results according
Search results are listed in order of relevance. System
to relevance - most relevant search results
documentation describes the algorithm(s) used to
appearing at the beginning of the list, gradually
rank search results.
decreasing in relevance to the bottom of the list.
1.3 MAINTAIN OR USE RECORDS
1.3.5 Records Preservation
Criterion 1.3.5.1: The system provides users the capability to read and accurately interpret all
records (and metadata) in the system throughout their useful life. The system
has capability to continuously sample older records for the ability to machine-
read records and their metadata, and reports failures to machine -read.
Sample Test(s)
Expected Result(s)
Set sampling criteria, age, and periodicity parameters for
System accepts the sampling parameters.
sampling older records (e.g., 1 percent sample of
records older than 3 years, run once each week).
Run sampling process to machine-read sampled records,
System will successfully run the records/metadata
reporting function, and output function.
sampling process continuously as per instructions.
Ensure system is set for continuous running of sampling
System successfully reports machine-readability results
process.
for sampling process.
System successfully outputs set of older records for
human readability.
13 Wildcard characters can be used in queries in place of unknown characters and to search for multiple variations of
a term. For example, searching on “terror*” would retrieve data that include “terror,” “terrorist,” “terrorism,” etc.
14 Exact-match searches return data that include the exact search string; also known as “on-the-nose” search
15 Proximity or adjacency searches return data that include search strings within a certain “distance” of other strings,
(e.g., when the word “fire” is within 50 characters of “explosion.”)
16 Relevance ranking is a system mechanism that determines the degree to which the retrieved data are relevant to
the search.
17 Stop words are extremely common words that a search engine will not search for in order to save space or to
speed up searches. Examples include: "the," “it,” “and,” “a," “or,” etc.
For Official Use Only
C-6
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Criterion 1.3.5.2: The system enables migration of records and metadata to new storage media
or formats in a way that the content is retained and understandable in order to
avoid loss due to media decay or technology obsolescence.
Sample Test(s)
Expected Result(s)
Select a set of records and metadata. Convert the
The converted records and metadata are opened
records to the standard FBI software format for
successfully in the new software format. The
migrating records.
records and metadata content has not changed and
remains readable and understandable.
Export a set of records and metadata to another system
Selected set of records and metadata are successfully
and verify receipt of export.
imported to another system. The records and
metadata content has not changed and remains
readable and understandable.
Criterion 1.3.5.3: The system ensures that captured metadata remains linked to appropriate
records without alteration throughout the useful life of the records. The
system supports the capability to continuously sample records to verify that
metadata remain associated with records and to output results of the sampling
process.
Sample Test(s)
Expected Result(s)
Set sampling criteria and periodicity for sampling records
Sampling criteria and periodicity will be successfully set.
(e.g., 1 percent sample of all records, run once each
week).
Run sampling process to verify that records remain
Sampled records are associated with their metadata.
associated with their metadata.
Run reporting function, and output function.
Errors in associating records and metadata are reported
Ensure system is set for continuous running of sampling
System continuously runs the sampling process.
process.
1.3 MAINTAIN OR USE RECORDS
1.3.6 Audit/Oversight
Criterion 1.3.6.1: The system provides access to summary reports (e.g., number of accesses)
and detail level audit trail information (e.g., each individual record access,
including record identifier, date, time and user). The system supports the
capability to continuously compile and output periodic and on-demand reports
of summary and detailed audit trail information.
Sample Test(s)
Expected Result(s)
Set formats, data elements, parameters, and periodicity
Periodic audit trail reports are successfully compiled and
for audit trail reports.
output according to set formats, data elements,
parameters, and periodicity.
Perform, output, and/or provide user access to periodic
On-demand audit trail reports are successfully output
audit trail report.
and/or prepared for access.
Perform, output, and/or provide user access to on-
System continuously runs the audit trail report function.
demand audit trail report.
Set system for continuous running of audit trail report
function.
Criterion 1.3.6.2: The system tracks failed attempts of all records activity and system functions.
In other words, the system detects, records and outputs any unsuccessful
attempts to access records or metadata, or conduct other system functions.
The system tracks information such as user ID, date and time of failed
attempts.
Sample Test(s)
Expected Result(s)
For Official Use Only
C-7
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Using an unauthorized user ID, attempt to modify a
Failed attempt at record modification is detected,
record.
recorded, and output.
Using an unauthorized user ID, attempt to modify user
Failed attempt at modification of user access permissions
access permissions.
is detected, recorded, and output.
Criterion 1.3.6.3: Audit trail information is managed as records in order to prevent editing of
audit logs.
Sample Test(s)
Expected Result(s)
Perform set of actions resulting in audit trail activity.
Audit trail activity is recorded as expected.
Either manually or automatically, declare the audit trail
Audit trail report is declared a record and its associated
report a record and enter associated metadata.
metadata is linked to the record.
Verify that each audit trail report is declared a record
with associated metadata.
1.4 DISPOSE OF RECORDS (FINAL) (Transfer or Destroy)
Criterion 1.4.1:
The system identifies records eligible for transfer or destruction based on
records retention schedules and disposition instructions (i.e., the system
automatically detects when a record’s retention period will pass, notifies the
Records Officer that the record is eligible for disposition, and stipulates
whether the record is eligible for transfer or destruction).
Sample Test(s)
Expected Result(s)
Develop a test set of records in the system that is eligible
Records Officer is notified by the system that the set of
for disposition tomorrow.
records is eligible for disposition.
Records Officer is informed by the system which records
are eligible for transfer and which for destruction.
Criterion 1.4.2:
The system exports records and metadata to be transferred (i.e., copy and
subsequently remove them from the system) in a format acceptable for
transfer to NARA18.
Sample Test(s)
Expected Result(s)
Verify in system documentation that records can be
exported in NARA-accepted formats.
Issue export command for a set of records.
Records are copied to an outside system or media; in
NARA-acceptable formats.
Criterion 1.4.3:
The system deletes records to be destroyed so they cannot be physically
reconstructed or otherwise retrieved.
Sample Test(s)
Expected Result(s)
Insert set of records and metadata to be destroyed.
Issue destruction command for the records and metadata.
Designated records and metadata are deleted from the
system.
Attempt to retrieve and reconstruct the records and
Neither the system nor any external procedures or
metadata.
software is successful in retrieving or reconstructing
the records and metadata.
Criterion 1.4.4:
The system maintains a record of all record transfers and destructions and
provides certifiable proof of transfer or destruction. All records of transfer or
destruction are treated as records.
18 Contact NARA for acceptable transfer formats. See 36 CFR 1228.270. Transfer formats are specified in records
retention schedules.
For Official Use Only
C-8
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Sample Test(s)
Expected Result(s)
Insert set of records and metadata to be destroyed.
Issue destruction command for the records and metadata.
Declare fact of destruction of records/metadata to be a
Records of destructions are maintained.
record for each member of set.
Records of destruction are not themselves capable of
being destroyed.
1.5 PROCESS RECORDS CONTAINING RESTRICTED OR NATIONAL SECURITY
CLASSIFIED DATA
Criterion 1.5.1:
The system captures National Security Classification metadata for classified
records. These metadata elements include current classification, reason for
(authority), classification source, derivative source (if any), declassification
date, downgrade instructions, review date, reviewer, declassification date, and
declassifier.
Sample Test(s)
Expected Result(s)
Import set of national security classified records to the
Imported national security classified records are accepted
system.
successfully in system with associated metadata.
Using an authorized user ID, enter metadata stipulating
Metadata stipulating classification status, plus additional
the records are classified for purposes of national
related metadata, are successfully entered in the
security, and populate additional classification-
system.
related metadata elements.
Criterion 1.5.2:
For derivatively classified records, the system supports the capability to
capture multiple reasons [“Reason(s) for Classification”] and multiple sources
(“Classified By”) metadata elements.
Sample Test(s)
Expected Result(s)
Import or designate a set of derivatively classified
Set of derivatively classified records is successfully
records.
designated or imported.
Assign multiple reasons and multiples sources in the
Associated metadata for derivatively classified records
associated metadata for each record
successfully accepts multiple values for reasons and
sources.
Criterion 1.5.3:
The system provides a method for assigning classification levels to records
(e.g., through a data or metadata field). The classification levels should
include, but not be limited to: Confidential, Secret, Top Secret, and No
Marking.
Sample Test(s)
Expected Result(s)
Enter five records and assign a different classification
Each record includes in its metadata a Confidential,
level to each record.
Secret, Top Secret, or No Marking classification.
Criterion 1.5.4:
Authorized users can make changes to the retention period before
declassification.
[Note: Declassification review occurs outside the system.]
Sample Test(s)
Expected Result(s)
Use an authorized user ID to modify the retention period
For the designated set of records, the retention period is
for a set of records.
successfully modified.
1.6 INTERFACE WITH RMA (EXPORT RECORDS)
Criterion 1.6.1:
The system exports records and history to the RMA.
Sample Test(s)
Expected Result(s)
Issue command to export a declared record and its
Set of records and history are successfully received by
history to the RMA.
the RMA.
The system no longer contains the exported set of
records and metadata.
For Official Use Only
C-9
Version 1.0
FBI Electronic Recordkeeping
Appendix C
Certification Manual
ERKC Assessment Criteria
Criterion 1.6.2:
The system exports metadata attached to records to the RMA.
Sample Test(s)
Expected Result(s)
Issue command to export the metadata for a declared
Set of metadata is successfully received by the RMA with
record to the RMA.
the record.
The system no longer contains the exported set of
records and metadata.
Criterion 1.6.3:
The system identifies and exports associated (linked) records and maintains
record relationships.
Sample Test(s)
Expected Result(s)
Select a test record that has associated records. Export
The known associated records are transferred to the
the record to the RMA, indicating, if necessary, that
RMA. The relationship between the records is
you also want to transfer any associated records.
maintained in the RMA.
Criterion 1.6.4:
The system supports the capability to add needed metadata when records are
exported.
Sample Test(s)
Expected Result(s)
Access metadata of exported record from the sample test
Metadata file is accessed.
for Criterion 1.6.2 and fill in missing fields.
Metadata is successfully added.
Criterion 1.6.5:
The system maintains pointers to exported records (i.e., associated
records in the system should be linked to the exported record in the RMA). When a record is
transferred from one system to another (the RMA), its "location" changes. Any pointers that
pointed to the record in its "old location" need to be modified to reflect its "new location." For
example, the system may contain past versions of a document (these versions may not be records,
but documents), and the latest version is being transferred to a new RMA [possibly from a
document management application (DMA)]. When a user opens up an outdated version of that
document, the system should indicate that the latest version is located in the RMA.
Sample Test(s)
Expected Result(s)
Issue command to export a record with associated
Pointers in system will reflect the RMA identifier for the
records to the RMA.
moved/exported record.
Criterion 1.6.6:
Unique identifiers are transferred from source systems to the RMA (i.e., the
system sends the unique identifier for a record from the original system to the
RMA when a record is transferred to the RMA).
Sample Test(s)
Expected Result(s)
Issue command to export a record from the system to the
The original system’s correct unique identifier is located in
RMA. In the RMA, check the status of the field for
the metadata of the record in the RMA.
the original identifier.
v v v
For Official Use Only
C-10
Version 1.0
FBI Electronic Recordkeeping
Appendix D
Certification Manual
ERKC Process Flow for Legacy Systems
Appendix D—ERKC Process Flow for New Systems
ERKC Approach for New Systems
Definition
Verification
Validation (continues on next page)
System
Risk
ERK
Requirements
Test
Mitigation
Test Plan
Approach
Document
Results
Plan
Entity
System
Assess ERK
Establish ERK
Develop
Develop
Acceptance
Document
Risk
criteria
approach
System
Test Plan
Test
Results
Mitigation
Owner
Rqmts
Plan
Meet with
YES
System
Owners
RO
Advise on
Review
System
Request
Advise on
Advise on
Support
Evaluate
Evaluate
ERK
Review
NO
documents
Report
contain
FBI
Mitigation
criteria
Rqmts
Test Plan
Test
Results
Plan
Compliance
Intranet
Document
Plan
(As requested)
:
(As requested)
(As requested)
NO
(As requested)
• ERK criteria
NO
YES
YES
• ERK guidance
Desc ription
Certification
RMD
Description
of ERKC
Evaluation
of System
Certification
Databas
Worksheet
Approach
Report
e
START
• Descriptions of
Systems not
containing
Certify
Certify
NATO
records
(ATO)
(IATO
• Descriptions of
Systems
Documentat
containing
ion
records
ATO
IATO
• Business Plans (Exhibits
300, 53)
• System Security Plans
• EA Applications
Architecture
For Official Use Only
D-1
Version 1.0
FBI Electronic Recordkeeping
Appendix D
Certification Manual
ERKC Process Flow for Legacy Systems
ERKC Approach for New Systems
Post Certification
Risk
Mitigation
Plan
Entity
Provide
Risk
System
relevant
Mitigation
documentation
Plan
Owner
RO
Monitor
Notify of
NO
Request
Evaluate
IATO/ATO
system
Evaluate
Mitigation
Plan
Compliance
Expiration
recertification
Plan
NO
YES
YES
Certification
Report
Certify
Certify
NATO
(ATO)
(IATO)
ATO
IATO
For Official Use Only
D-2
Version 1.0
FBI Electronic Recordkeeping
Appendix E
Certification Manual
ERKC Process Flow for Legacy Systems
Appendix E—ERKC Process Flow for Legacy Systems
ERKC Approach for Legacy Systems
Validation (continues on next page)
Test Plan &
Test Results
Entity
Demonstrate
Meet with
Provide
System
RO
Documentation
System
NO
Owner
Update
RO
Request
Review System
Identify
YES
Criteria
System
System
Certification
System
Documentation
System
contains
Met?
Evaluation
Certification
Documentation
Worksheet
records
Report
NO
YES
Report Risks
and Mitigating
A
Request for
Certification
System
Evaluation
Factors
RMD
Documentation
Worksheet
Database
(Go to next page)
START
Certification
• Descriptions of
Report
Systems not
containing records
• Descriptions of
Documentatio
Systems
n
containing records
• Business Plans (Exhibits 300,
53)
• System Security Plans
• EA Applications Architecture
For Official Use Only
E-1
Version 1.0
FBI Electronic Recordkeeping
Appendix E
Certification Manual
ERKC Process Flow for Legacy Systems
ERKC Approach for Legacy Systems
Validation (continues from previous page)
Mitigation Plan
Entity
Prepare
Update
STOP
Mitigation
System
Mitigation
Plan
Plan
Owner
RO
NO
NO
Request
A
Risks
Review
Plan
Mitigation
Acceptable?
Mitigation
Feasible?
Plan
(From
?
Plan
Previous page)
YES
YES
Certify
Certify
Issue
(IATO)
NATO
(ATO)
IATO
NATO
ATO
For Official Use Only
E-2
Version 1.0
FBI Electronic Recordkeeping
Appendix F
Certification Manual
Risk Management
Appendix F—Risk Management
his appendix provides guidance on performing risk management in the context of
T
determining vulnerabilities associated with the processing and use of electronic records. It is
based on the electronic recordkeeping
(ERK) criteria for FBI information systems
(ISs)
presented in Appendix C. The primary source of material for the information in Appendix F is
NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems,
Risk Management provides a systematic process designed to identify and minimize the effects of
risks and uncertainties. Risk management activities make risks visible and include assessing the
probability of a risk’s occurrence and its potential adverse effect. The potential adverse effect
quantifies the magnitude of the loss to the effectiveness of Records Management in the FBI
should the system be operated as an FBI IS.
Risk assessment is used to determine the extent of potential threats and risk associated with an IS
throughout its system development life cycle (SDLC). The results of this process help to identify
areas of concern—instances in which an FBI IS does not comply with ERK criteria—so the
Records Officer (RO) can make a decision regarding system certification.
The electronic recordkeeping certification (ERKC) risk management process, described in the
remainder of this appendix, is a guide for measuring potential ERK risk and reporting the level
of that risk
(i.e., its
“seriousness”) with respect to the ERK criteria for the system under
consideration. The RO will use the results of an evaluation of risk (and any associated risk
mitigation plans) in making the decision whether, and under what conditions, to certify an
information system.
As noted above, the primary risk management activities are (1) risk analysis and (2) risk
mitigation. Section F.1 describes the former and Section F.2 provides guidance on the latter.
F.1 Analyzing Risk
Figure F-1 provides an overview of the risk analysis process using the results of an evaluation of
system compliance against ERK criteria. As noted in the figure, the process relies on the use of
system documentation as its principal input. The process involves four primary activities, which
are explained in the sections noted below:
§ Tailor the ERK Compliance Evaluation Worksheet (Section F.1.1).
§ Analyze system documentation (Section F.1.2).
§ Determine the system risk scores (Section F.1.3).
§ Determine the system risk level (Section F.1.4).
For Official Use Only
F-1
Version 1.0
FBI Electronic Recordkeeping
Appendix F
Certification Manual
Risk Management
Analyze Test
System
Results
Documentation
Determine
Determine
(Section F.1.1)
(Requirements specs
System Risk
System Risk
System
and test plans)
Risk
Scores
Level
Determine Risk
(Section F.1.3)
(Section F.1.4)
Level
ERK Compliance
Evaluation Worksheet
Factors
(risk criteria with
(Section F.1.2)
baseline values)
Report Risks and
Mitigating
Factors
(Section F.1.5)
Figure F-1. ERKC Risk Analysis Process
F.1.1 Tailor ERK Compliance Evaluation Worksheet
The first step in the risk analysis process is for the Evaluator to determine, using the ERK
Criteria Tailoring Tool, which criteria are applicable for evaluation. This determination is based
upon the system’s ERK “approach” and other system characteristics. The ERK Criteria
Tailoring Tool is located in Appendix H. Section 1.4 provides information on the different
architectural approaches to satisfying the ERK criteria.
In the ERK Compliance Evaluation Worksheet, located in Appendix I, the Evaluator directly
assigns the Compliance Value to 1 for those criteria that are not applicable to the system, and
makes a notation in the Comments column indicating the non-applicability of the criterion.
Assigning a Compliance Value of 1 to non-applicable criteria ensures that systems are not
described as being at higher risk should particular ERK criteria not apply.
Examples of other system characteristics that would make specific criteria not applicable (and
therefore directly assigned a Compliance Value of 1 include the following:
§ If the system under consideration does not contain Vital Records, the criterion relating to
such records may have a Compliance Value of 1.
§ If the system under consideration does not contain restricted or national security classified
information, the criteria relating to such records may have a Compliance Value of 1.
In addition to the tailoring guidance provided by the ERK Criteria Tailoring tool, RMD is
available to provide additional guidance on the assignment of Compliance Values.
F.1.2 Analyze System Documentation
In parallel with tailoring the ERK Compliance Evaluation Worksheet, the Evaluator analyzes the
required system documentation developed in compliance with the FBI SDLC and examines it for
evidence of functionality that satisfies the ERK Assessment Criteria. The Evaluator records the
examination results in the ERK Compliance Evaluation Worksheet.
For Official Use Only
F-2
Version 1.0
FBI Electronic Recordkeeping
Appendix F
Certification Manual
Risk Management
§ If the evidence found in the documentation fully satisfies the ERK criterion, the ERKC
Evaluator will assign a Compliance Value of 1, meaning the system satisfies this criterion
100 percent.
§ If the evidence found in the documentation satisfies some percentage of the ERK criteria,
the Compliance Value assigned is that percentage (expressed as a decimal between 0 and
1), which is multiplied by the Risk Baseline associated with the particular ERK risk
criterion to calculate the Risk Score.
§ As mentioned in Section F.1.1, if the risk criterion is not applicable to the system under
consideration, the Compliance Value assigned is 1
- this ensures that systems are not
described as being at higher risk should particular ERK criteria not apply. For example,
certain ERK criteria are relevant only to those systems that contain classified information.
Systems that do not contain classified information should not have a lower overall Risk
Score (i.e. represent higher risk) because certain criteria are not applicable.
F.1.3 Determine System Risk Scores
For each criterion, compute the risk score by multiplying the Risk Baseline by the Compliance
Value. In equation form, this can be expressed as:
Risk Score = Risk Baseline r Compliance Value
For example, if a criterion’s Risk Baseline is 5 and the compliance value is 0.5, (the Evaluator
has determined that the system only half satisfies the criterion), the Risk Score would equal 2.5.
If the Compliance Value is set to 1 - because the criterion does not apply to the system or the
system fully satisfies the criteria - then the Risk Score will equal the Risk Baseline.
F.1.4 Determine System Risk Level
The final step in the process is to determine the overall system risk level. This step involves
computing the overall Risk Score and analyzing the results. Such an analysis must include
examination of the potential implications of a system not meeting certain ERK criteria,
consideration of mitigating factors, as well as an examination of the risks aggregated into their
risk classes (Declare Records, Capture Records, etc.).
To compute the overall risk score, sum the individual risk scores for all criteria (including those
that were deemed not applicable to the system). Because there are complementary risks within
classes, the class- level risk must also be calculated. It is important to note that the lower the risk
score, the higher the overall risk.
An important aspect of the risk analysis is to determine the potential implications associated with
any criteria for which less-than-complete satisfaction was demonstrated by the test results (i.e.,
those criteria for which the compliance value is less than one). The System Owner must use his
or her judgment (perhaps working in cooperation with the RMD) to develop these potential
implications. The Comment column in the ERK Compliance Evaluation Worksheet may be used
to record the implications. This information will serve as the foundation for any mitigation plan
to be developed by the System Owner to obtain an Interim Authority to Operate (IATO) - see
Sections 2.2.3 and 2.3.1, respectively, for information on risk mitigation plans for new and
legacy systems.
For Official Use Only
F-3
Version 1.0
FBI Electronic Recordkeeping
Appendix F
Certification Manual
Risk Management
F.1.5 Report Risks and Mitigating Factors
Using the completed ERK Compliance Evaluation Worksheet and notes from meetings with the
System Owner, the ERKC Evaluator develops the ERK System Certification Report. The report
summarizes the results of the system evaluation and should focus on descriptions of risks and
unique system characteristics that either mitigate or exacerbate risk. The report is organized by
the 11 criteria classes (Declare Records, Capture Records, etc.) to ensure that related risks are
discussed together to provide sufficient context to support a certification decision by the RO. A
template of this report is located in Appendix J. The final ERK System Certification Report
consists of this risk analysis supported by the final completed ERK Compliance Evaluation
Worksheet.
F.2 Mitigating Risk
Each risk identified as a result of the risk analysis process should have a mitigation strategy.
(This is mandatory if the RO requires a System Owner to prepare a risk mitigation plan.) Risk
mitigation is the analysis of trade-offs among alternative sets of possible safeguards. A
mitigation countermeasure is the method that will be taken to lessen or alleviate the adverse
effect of the risk. For ERKC, the ultimate recommended countermeasure would be the selection
and implementation of one of the approved ERK approaches (see section 1.4 for definitions of
these approaches). However, interim countermeasures may also be effective in reducing the
system risk level.
Examples of possible mitigation strategies include:
§ Using an alternative method of storing records (e.g., printing out and filing records in
paper form) until the ability to transfer records to the FBI RMA is built into the system.
§ Including the desired feature in the next version of the system that is funded for the
following year.
§ Determining that the system is a temporary one and will outlive its usefulness (or be
replaced) within the following year.
Using the information in the ERK Compliance Evaluation Worksheet, the System Owner should
create a risk mitigation plan (also called an action plan). One method would be to extract the
criterion number and the potential implication and put them in the ERK Risk Mitigation
Worksheet shown below.
The System Owner may then document the mitigation
countermeasures or recommended countermeasures in the worksheet. Implications and
countermeasures should have a one-to-one relationship. The Risk Mitigation Worksheet
provides the core content of a risk mitigation plan, should the latter be required by the RO.
ERK Risk Mitigation Worksheet
Criterion
Mitigation / Recommended
Potential Implication
Number
Countermeasures
For Official Use Only
F-4
Version 1.0
FBI Electronic Recordkeeping
Appendix G
Certification Manual
Risk Management
Appendix G—System Evaluation Process Details
This appendix provides detailed instructions for evaluating how well the system under
consideration complies with the electronic recordkeeping (ERK) Assessment Criteria.
The Validation phase of the electronic recordkeeping certification (ERKC) process is designed to
identify how well the system satisfies the ERK criteria. It is designed to take advantage of
existing system documentation to avoid dup lication of effort and placing additional unnecessary
burden on the System Owner. Figure G-1 depicts an overview of this process and describes how
the various tools, worksheets, and criteria contained in the appendices of this manual are used
together to evaluate information systems for compliance with ERK criteria.
The primary inputs to this process are:
§ ERK Assessment Criteria (Appendix C)
§ ERK Criteria Tailoring Tool (Appendix H)
§ System documentation
§ ERK Compliance Evaluation Worksheet (Appendix I)
§ List of RMA Metadata (Appendix M)
Gather
ERK Tailoring
RMA Metadata
System
ERKC
ERK Criteria
Materials
Tool
Documentation
Evaluation Form
Section G.1
Section G.2
ERKC
Provide
Conduct
Review
Evaluation
Additional
Evaluation
Evaluation
Report
Information
Develop
Draft
Action
EC and Letter
Plan
Section G.3
ERK EC
Action Plan
ERKC letter
Records
Officer
Figure G-1. ERKC Validation Phase Process
For Official Use Only
G-1
Version 1.0
FBI Electronic Recordkeeping
Appendix G
Certification Manual
Risk Management
G.1 Prepare for the Validation Phase
The Evaluator assembles the materials. The system documentation is provided by the System
Owner. The ERK Assessment Criteria, the ERK Criteria Tailoring Tool, ERK Compliance
Evaluation Worksheet, and List of RMA Metadata are included as appendices to this Manual and
will be available on the RMD Web site.
The most useful system documentation to support the validation phase process is the test results
from a system functional test and a Security Certification and Accreditation (C&A) test. If these
are not available, the system requirements would be most useful, after which would be system
design documents or user’s manual.
With knowledge of the ERK approach of the system (i.e., Integration, Direct Export, or Integral),
the ERK Criteria Tailoring Tool is used to tailor the criteria to those required by the system.
Following the instructions for the tool, a Compliance Value of 1 can be entered on the ERK
Compliance Evaluation Worksheet (as described in Section F.1.1) for non-applicable criteria
prior to any detailed examination of the system documentation.
G.2 Evaluate System Compliance
As shown in Figure G-1, the evaluation process mainly consists of an interaction, or series of
interactions, between the ERK Evaluator and the System Owner. Proper evaluation cannot be
conducted without an understanding of the context of the subject application, as well as the role
of the system in the business.
Initially, the Evaluator follows the steps in the risk analysis process described in section F.1.2,
matching the documentation with the ERK Assessment Criteria and using its tests and expected
results as aids to determine what criteria are met according to the system documentation. The
List of RMA Metadata, which includes all required FBI RMA metadata elements, is used in
evaluating the criteria that address metadata. The list is presented in Appendix M.
The Evaluator uses the evaluation worksheet to document the results of the evaluation, making
notes in the Comment column for any criterion that does not appear to be satisfied, or for which
questions remain. The Adverse Effect column can be modified to include specific adverse
effects from the unmet criteria.
After the evaluation of the system documentation is documented in a draft ERK Compliance
Evaluation Worksheet, the Evaluator meets with the System Owner to review the results. The
goal of this meeting is not to defend preliminary assessments, but to develop a common
understanding of both the system and the ERK criteria. During this meeting, adjustments to the
Compliance Values are encouraged as the ERK Evaluator gains further insight into the system.
As much of the success of this process depends on System Owners understanding the ERK
criteria so that they can develop appropriate requirements specifications that will lead eventually
to full compliance, the ERK Evaluator must strive to promote understanding and help the System
Owner identify ways to satisfy ERKC requirements. Oftentimes, for example, systems support
For Official Use Only
G-2
Version 1.0
FBI Electronic Recordkeeping
Appendix G
Certification Manual
Risk Management
business processes result in records, but systems owners may not be aware that a final approval
that results in the publishing of a document, or Web page, may constitute the declaration of a
record, and that only minor changes may be required to fully comply with relevant records
declaration criteria.
System Owners should be encouraged to provide additional documentation as evidence of
compliance with ERK criteria. Oftentimes, fo r example, systems maintain audit information that
is not documented in either requirements specifications or test plans as end-users rarely have use
for such information. Sample audit reports are excellent evidence of compliance with audit
related criteria. Responsibilities for training to help the System Owner understand how to treat
audit data as records, however, should be assumed by the ERK Evaluator.
G.3 Document the Evaluation
Using the completed ERK Compliance Evaluation Worksheet and notes from meetings with the
System Owner, the ERKC Evaluator develops the ERK System Certification Report. The report
summarizes the results of the system evaluation and should focus on descriptions of risks and
unique system characteristics that either mitigate or exacerbate risk. The Worksheet should be
included as an appendix to the Report.
When the System Owner and Evaluator agree that the ERK System Certification Report
accurately represents the situation, the System Owner develops a risk mitigation plan (also
known as an action plan) for the unmet ERK criteria, as discussed in section F.2.
The Evaluator drafts the ERK Certification Letter and the ERKC Electronic Communication
(EC). The purpose of the Letter is to certify the system and delineate the terms of the
certification. The purpose of the ERKC EC is to notify the System Owner of the certification. A
sample Letter and EC are included Appendices K and L, respectively, and will be available on
the RMD Web site.
The outputs from the process are:
§ Completed ERK System Certification Report, including the ERK Compliance Evaluation
Worksheet as an appendix (Appendix J)
§ System Risk Mitigation Plan (if needed)
§ Draft ERK Certification Letter (Appendix K)
§ Draft ERK Electronic Communication (Appendix L)
The outputs from this process are sent to the Records Officer as input for the decision whether or
not to authorize the operation of the system.
For Official Use Only
G-3
Version 1.0
FBI Electronic Recordkeeping
Appendix H
Certification Manual
Risk Management
Appendix H—ERK Criteria Tailoring Tool
The ERK Criteria Tailoring Tool is used to determine which ERK criteria are to be included in
the system according to the ERK approach determined by the System Owner or project manager.
Find the column in the table that correlates to the ERK approach of the system. Those criteria
marked with an “X” in that column should be included in the system’s design to ensure
compliance with the FBI electronic recordkeeping certification process.
Integration
Direct
Criterion
Integral
With RMA
Export
1.1 DECLARE RECORDS (Allow information to be designated as a record)
1.1.1 The system designates specified information as records,
X
X
either manually or automatically.
1.1.2 The system assigns unique identifiers to records and
their associated metadata. The system prevents any
X
X
X
modification of a record's unique identifier, once it is
defined.
1.1.3 The system captures record metadata (FBI-
X
X
designated and others) automatically and reliably links
metadata to the records.
1.2 CAPTURE RECORDS
1.2.1 The system imports records from sources outside the
system (e.g., other information systems, desktop
applications, scanned documents, or e-mail) along with all
X
X
required associated metadata (e.g., records series, pre-
existing file plans, or locations for physical records)
1.2.2 To provide records management control over the
records without physically transporting them to an RMA,
X
X
X
the system links records to an external RMA.
1.3 MAINTAIN OR USE RECORDS
1.3.1 RECORDS ORGANIZATION
1.3.1.1 The system accepts an FBI-specific scheme for
organizing records. For example, the system accepts FBI-
X
X
specific records retention schedules and organizes records
according to the schedules.
1.3.1.2 Users can select categories in which records are
X
X
filed and assign records to these categories.
For Official Use Only
H-1
Version 1.0
FBI Electronic Recordkeeping
Appendix H
Certification Manual
Risk Management
Integration
Direct
Criterion
Integral
With RMA
Export
1.3.1.3 The system supports assignment of Vital Record
X
X
indicators.
1.3.1.4 The system supports linking of related records (e.g.,
a redacted record with its non-redacted counterpart, an
X
X
original record with its revision, or an electronic record
with a paper antecedent).
1.3.1.5 The system supports the capability for users to
create and edit file plans, including categories and sub-
X
X
categories. The system prevents deletion of non-empty
folders.
1.3.1.6 The system can assign a status to records to prevent
destruction (i.e., the system contains an indicator that
includes an option to mark records as “do- not-destroy,”
X
X
which prevents records from being selected for
destruction or transfer according to records retention
schedules).
1.3.1.7 The system supports global changes to metadata,
X
file plans, and records retention schedules.
1.3.1.8 The system executes disposition instructions (e.g.,
moves a group of records from active to inactive status or
X
designates a group of records for destruction or transfer).
1.3.1.9 For systems that manage physical records, the
system specifies identifiers for boxes, contents, locations,
etc. In other words, the system stores metadata for
X
records not contained in the system and can identify
records by physical location (box number, location ID,
etc.)
1.3.2 RECORDS SECURITY
1.3.2.1 The system prevents over-writing records. To
comply with records management guidelines, records are
X
X
X
never edited, but new versions are created and linked to
the source.
1.3.2.2 The system prevents deletion of indices, categories,
and other 'pointers' to records (i.e., maintains referential
X
X
X
integrity).
1.3.2.3 The system provides an automatic method to detect
X
X
any alteration of records or metadata.
For Official Use Only
H-2
Version 1.0
FBI Electronic Recordkeeping
Appendix H
Certification Manual
Risk Management
Integration
Direct
Criterion
Integral
With RMA
Export
1.3.2.4 The system provides audit trails of all add, update,
X
X
X
deletion, and retrieval activity.
1.3.2.5 The system (or System Owner) maintains
appropriate backup copies of records and recordkeeping
X
X
X
systems.
1.3.2.6 The system is protected by adequate
recovery/rollback and rebuild procedures so that records
X
X
X
may be recovered or restored following a system
malfunction.
1.3.3 RECORDS ACCESS
1.3.3.1 The system controls access so that only authorized
individuals are able to retrieve, view, print, copy, or edit
X
records or other entities (e.g., metadata, file plan, etc.) in
the recordkeeping system.
1.3.3.2 The system identifies individuals and groups of
users and allows different access privileges to be assigned
X
X
to individuals or groups.
1.3.3.3 The system maintains the integrity of redacted
records and assures that redacted material is not accessible
X
X
X
on sealed records.
1.3.4 RECORDS RETRIEVAL
1.3.4.1 The system ensures that all access privileges
(permissions and restrictions) are enforced on all
X
retrievals.
1.3.4.2 The system can retrieve records and their associated
metadata and can retrieve records based on defined links
X
(e.g., between versions of the same record or between the
records in a particular case file).
1.3.4.3 The system provides a sufficiently powerful range
of search features and options, as needed to meet agency
requirements. These might include: searching on
individual terms or a combination of terms, wildcard or
X
exact-match searching, proximity or adjacency searching,
relevance ranking of search results, use of stop words,
limits on maximum size of results set from a search, query
by image content, or others.
For Official Use Only
H-3
Version 1.0
FBI Electronic Recordkeeping
Appendix H
Certification Manual
Risk Management
Integration
Direct
Criterion
Integral
With RMA
Export
1.3.5 RECORDS PRESERVATION
1.3.5.1 The system provides users the capability to read and
accurately interpret all records (and metadata) in the
system throughout their useful life. The system has
X
capability to continuously sample older records for the
ability to machine-read records and their metadata, and
reports failures to machine-read.
1.3.5.2 The system enables migratio n of records and
metadata to new storage media or formats in a way that
the content is retained and understandable in order to
X
avoid loss due to media decay or technology
obsolescence.
1.3.5.3 The system ensures that captured metadata remains
linked to appropriate records without alteration
throughout the useful life of the records. The system
X
supports the capability to continuously sample records to
verify that metadata remain associated with records and to
output results of the sampling process.
1.3.6 AUDIT/OVERSIGHT
1.3.6.1 The system provides access to summary reports
(e.g., number of accesses) and detail level audit trail
information (e.g., each individual record access, including
record identifier, date, time and user). The system
X
supports the capability to continuously compile and output
periodic and on-demand reports of summary and detailed
audit trail information.
1.3.6.2 The system tracks failed attempts of all records
activity and system functions. In other words, the system
detects, records and outputs any unsuccessful attempts to
X
access records or metadata, or conduct other system
functions. The system tracks information such as user ID,
date and time of failed attempts.
1.3.6.3 Audit trail information is managed as records in
X
X
order to prevent editing of audit logs.
For Official Use Only
H-4
Version 1.0
FBI Electronic Recordkeeping
Appendix H
Certification Manual
Risk Management
Integration
Direct
Criterion
Integral
With RMA
Export
1.4 DISPOSE OF RECORDS (FINAL) (Transfer or destroy)
1.4.1 The system identifies records eligible for transfer or
destruction based on records retention schedules and
disposition instructions (i.e., the system automatically
detects when a record’s retention period will pass, notifies
X
the Records Officer that the record is eligible for
disposition, and stipulates whether the record is eligible
for transfer or destruction).
1.4.2 The system exports records and metadata to be
transferred (i.e., copy and subsequently remove them from
X
the system) in a format acceptable for transfer to NARA.
1.4.3 The system deletes records to be destroyed so they
X
X
X
cannot be physically reconstructed or otherwise retrie ved.
1.4.4 The system maintains a record of all record transfers
and destructions and provides certifiable proof of transfer
X
or destruction. All records of transfer or destruction are
treated as records.
1.5 PROCESS RECORDS CONTAINING RESTRICTED OR NATIONAL SECURITY
CLASSIFIED DATA (ERK systems maintaining restricted or national security classified
data shall:)
1.5.1 The system captures National Security Classification
metadata for classified records. These metadata elements
include current classification, reason for (authority),
X
X
X
classification source, derivative source (if any),
declassification date, downgrade instructions, review date,
reviewer, declassification date, and declassifier.
1.5.2 For derivatively classified records, the system
supports the capability to capture multiple reasons
X
X
[“Reason(s) for Classification”] and multiple sources
(“Classified By”) metadata elements.
1.5.3 The system provides a method for assigning
classification levels to records (e.g., through a data or
metadata field). The classification levels should include,
X
X
X
but not be limited to: Confidential, Secret, Top Secret, and
No Marking.
1.5.4 Authorized users can make changes to the retention
period before declassification.
[Note: Declassification
X
review occurs outside the system.]
For Official Use Only
H-5
Version 1.0
FBI Electronic Recordkeeping
Appendix H
Certification Manual
Risk Management
Integration
Direct
Criterion
Integral
With RMA
Export
1.6 INTERFACE WITH RMA (EXPORT RECORDS) (ERK systems that export records to an
RMA shall:)
1.6.1 The system exports records and history to the RMA.
X
1.6.2 The system exports metadata attached to records to
X
the RMA.
1.6.3 The system identifies and exports associated (linked)
X
records and maintains record relationships.
1.6.4 The system supports the capability to add needed
X
metadata when records are exported.
1.6.5 The system maintains pointers to exported records
(i.e., associated records in the system should be linked to
the exported record in the RMA). When a record is
transferred from one system to another (the RMA), its
"location" changes. Any pointers that pointed to the
record in its "old location" need to be modified to reflect
its "new location." For example, the system may contain
X
past versions of a document (these versions may not be
records, but documents), and the latest version is being
transferred to a new RMA [possibly from a document
management application (DMA)]. When a user opens up
an outdated version of that document, the system should
indicate that the latest version is located in the RMA.
1.6.6 Unique identifiers are transferred from source
systems to the RMA (i.e., the system sends the unique
X
identifier for a record from the original system to the
RMA when a record is transferred to the RMA).
For Official Use Only
H-6
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Appendix I—ERK Compliance Evaluation Worksheet
Electronic Recordkeeping (ERK) Compliance Evaluation Worksheet
[System Name]
Prepared by Electronic Records Section Staff
[Team Lead], Test Team Leader
Reviewed by [Reviewer’s Name]
Submitted on [Date]
For Official Use Only
I-1
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
The ERK Compliance Evaluation Worksheet consists of a table that lists each of the ERK Assessment Criteria and provides space in
the table columns to indicate the system’s compliance with each criterion and the implications of non-compliance or partial
compliance with particular criteria. The worksheet is completed during the Analyzing Risk Phase (Section F.1) of the ERKC process.
The Risk Baseline is a pre-filled column that contains the baseline value for each criterion. Baseline values are rated from 0 to 5; the
more critical the criterion, the higher the baseline value. Baseline values provide a starting point for determining the level of the risk
incurred by non-compliance or partial-compliance with the criterion, which is determined by evaluating how well the test results and
other system documentation reflect “satisfaction” against each criterion.
The Compliance Value column should be filled out by the Evaluator. The Compliance Value is rated on a scale of 0 to 1; a
Compliance Value of 1 indicates complete compliance with the criterion and a Compliance Value of 0 indicates total non-compliance.
If the criterion is half satisfied, the Compliance Value for that criterion would be 0.5.
The Risk Score column should also be completed by the Evaluator. The Risk Score is equal to the Risk Baseline multiplied by the
Compliance Value. For example, if the Risk Baseline for a particular criterion is 5, and the Compliance Value is 0.5, then the Risk
Score equals 2.5, or 5 r 0.5 = 2.5.
The Adverse Effect is a pre- filled column that describes the potential adverse effect if the criterion is not satisfied. However, the
contents of an individual cell may be modified to suit the particular system under evaluation.
The Comment column is a space for the Evaluator to note information such as aspects of the system related to the criterion or class,
and observances made during the risk analysis.
The ERK Criteria Tailoring Tool, described in Section F.1.1 and located in Appendix H, is used to determine which ERK criteria
below are applicable to the specific system. The tool consists of a table that lists each of the ERK Assessment Criteria and includes
columns for each ERK approach (i.e., Integration with RMA, Direct Export, or Integral). The Evaluator determines the column that
corresponds to the ERK approach of the system. Those criteria marked with an “X” in that column should be included in the system’s
design to ensure compliance with the FBI electronic recordkeeping certification process. All other criteria are not applicable to the
system under consideration and are not required for ERK certification of the system. In the ERK Compliance Evaluation Worksheet
below, the Compliance Value assigned to these non-applicable criteria is 1. Doing this ensures that the system does not have a lower
overall risk score (i.e. represent higher risk) should particular ERK criteria not apply.
For Official Use Only
I-2
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
The ERK Compliance Evaluation Worksheet should be included as an appendix to the ERK System Certification Report, a template of
which is located in Appendix J, and together they will be used by the Records Officer to make an ERK certification decision and
determine the level of certification the system will receive.
System:
<system name>
Test Team Lead
Reviewer
Test Team Member
Revision History
Revision Number
Date
Author(s)
Description of Changes
Draft
Draft with Corrections
Final Submitted Version
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.1 DECLARE RECORDS (Allow information to be designated as a record)
1.1.1 The system designates specified
Cannot link retention
5
information as records, either manually
information unless
or automatically.
identified as record.
1.1.2 The system assigns unique
Need unique identifier to
identifiers to records and their
differentiate between
5
associated metadata. The system
similar records.
prevents any modification of a record's
unique identifier, once it is defined.
1.1.3 The system captures record
Metadata not automatically
4
metadata (FBI-designated and others)
entered must be entered
automatically and reliably links
manually.
metadata to the records.
For Official Use Only
I-3
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
Class Summary
14
1.2 CAPTURE RECORDS
1.2.1 The system imports records from
Cannot import records.
sources outside the system (e.g., other
3
information systems, desktop
applications, scanned documents, or e-
mail) along with all required associated
metadata (e.g., records series, pre-
existing file plans, or locations for
physical records).
1.2.2 To provide records management
Cannot link to an RMA.
control over the records without
3
physically transporting them to an RMA,
the system links records to an external
RMA.
Class Summary
6
If the system cannot
capture records, it is
limited in the records that it
can contain.
1.3 MAINTAIN OR USE RECORDS
1.3.1 RECORDS ORGANIZATION
1.3.1.1 The system accepts an FBI-
Do not have basis for
5
specific scheme for organizing records.
retention and disposition.
For example, the system accepts FBI-
specific records retention schedules
and organizes records according to the
schedules.
1.3.1.2 Users can select categories in
Cannot assign retention
4
which records are filed and assign
and disposition.
records to these categories.
For Official Use Only
I-4
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.3.1.3 The system supports
Cannot automatically
3
assignment of Vital Record indicators.
identify vital records
contained in system.
1.3.1.4 The system supports linking of
If related records are not
3
related records (e.g., a redacted record
linked, it is harder to
with its non-redacted counterpart, an
identify all related records.
original record with its revision, or an
Run risk of working off
electronic record with a paper
wrong version.
antecedent).
1.3.1.5 The system supports the
Not limiting actions to
4
capability for users to create and edit
authorized users can
file plans, including categories and sub-
cause chaos and
categories. The system prevents
undermine the schedule.
deletion of non-empty folders.
1.3.1.6 The system can assign a status
Legal ramifications for
4
to records to prevent destruction (i.e.,
deleting records that
the system contains an indicator that
should have had action
includes an option to mark records as
suspended.
“do-not-destroy,” which prevents
records from being selected for
destruction or transfer according to
records retention schedules).
1.3.1.7 The system supports global
Use of more staff time to
changes to metadata, file plans, and
make individual changes
2
records retention schedules.
manually.
1.3.1.8 The system executes disposition
Manual searching for
instructions (e.g., moves a group of
records that are ready for
4
records from active to inactive status or
disposition.
designates a group of records for
destruction or transfer).
For Official Use Only
I-5
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.3.1.9 For systems that manage
Related physical and
physical records, the system specifies
electronic records are not
2
identifiers for boxes, contents, locations,
connected, could be “lost.”
etc. In other words, the system stores
metadata for records not contained in
the system and can identify records by
physical location (box number, location
ID, etc.)
Class Summary
30
1.3.2 RECORDS SECURITY
1.3.2.1 The system prevents over-
Degradation of reliability of
5
writing records. To comply with records
record keeping practices.
management guidelines, records are
never edited, but new versions are
created and linked to the source.
1.3.2.2 The system prevents deletion of
Degradation of reliability of
4
indices, categories, and other 'pointers'
record keeping practices.
to records (i.e., maintains referential
integrity).
1.3.2.3 The system provides an
Degradation of reliability of
4
automatic method to detect any
record keeping practices.
alteration of records or metadata.
1.3.2.4 The system provides audit trails
Degradation of reliability of
of all add, update, deletion, and retrieval
3
record keeping practices.
activity.
1.3.2.5 The system (or System Owner)
Loss of records if system
maintains appropriate backup copies of
3
malfunctions, power is
records and recordkeeping systems.
lost, etc.
For Official Use Only
I-6
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.3.2.6 The system is protected by
Loss of records if system
adequate recovery/rollback and rebuild
malfunctions, power is
3
procedures so that records may be
lost, etc.
recovered or restored following a
system malfunction.
Class Summary
22
1.3.3 RECORDS ACCESS
1.3.3.1 The system controls access so
Degradation of reliability of
that only authorized individuals are able
4
record keeping practices.
to retrieve, view, print, copy, or edit
records or other entities (e.g., metadata,
file plan, etc.) in the recordkeeping
system.
1.3.3.2 The system identifies individuals
Degradation of reliability of
and groups of users and allows different
4
record keeping practices.
access privileges to be assigned to
individuals or groups.
1.3.3.3 The system maintains the
Release of unauthorized
integrity of redacted records and
3
or personal information.
assures that redacted material is not
accessible on sealed records.
Class Summary
11
1.3.4 RECORDS RETRIEVAL
1.3.4.1 The system ensures that all
Degradation of reliability of
4
access privileges (permissions and
record keeping practices.
restrictions) are enforced on all
retrievals.
For Official Use Only
I-7
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.3.4.2 The system can retrieve records
Breakdown of links
and their associated metadata and can
between records and
3
retrieve records based on defined links
metadata or related
(e.g., between versions of the same
records require more staff
record or between the records in a
time to find records.
particular case file).
1.3.4.3 The system provides a
If search capabilities are
sufficiently powerful range of search
not robust enough, more
3
features and options, as needed to
staff time is spent finding
meet agency requirements. These
the correct records.
might include: searching on individual
terms or a combination of terms,
wildcard or exact-match searching,
proximity or adjacency searching,
relevance ranking of search results, use
of stop words, limits on maximum size
of results set from a search, query by
image content, or others.
Class Summary
10
1.3.5 RECORDS PRESERVATION
1.3.5.1 The system provides users the
Cannot use records.
capability to read and accurately
5
interpret all records (and metadata) in
the system throughout their useful life.
The system has capability to
continuously sample older records for
the ability to machine-read records and
their metadata, and reports failures to
machine-read.
For Official Use Only
I-8
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.3.5.2 The system enables migration of
Maintenance of outdated
records and metadata to new storage
4
technology for life of
media or formats in a way that the
records.
content is retained and understandable
in order to avoid loss due to media
decay or technology obsolescence.
1.3.5.3 The system ensures that
Lose of record integrity.
4
captured metadata remains linked to
appropriate records without alteration
throughout the useful life of the records.
The system supports the capability to
continuously sample records to verify
that metadata remain associated with
records and to output results of the
sampling process.
Class Summary
13
1.3.6 AUDIT/OVERSIGHT
1.3.6.1 The system provides access to
Staff time to get same
summary reports (e.g., number of
information manually.
3
accesses) and detail level audit trail
information (e.g., each individual record
access, including record identifier, date,
time and user). The system supports
the capability to continuously compile
and output periodic and on-demand
reports of summary and detailed audit
trail information.
For Official Use Only
I-9
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.3.6.2 The system tracks failed
Loss of audit reliability.
4
attempts of all records activity and
system functions. In other words, the
system detects, records and outputs
any unsuccessful attempts to access
records or metadata, or conduct other
system functions. The system tracks
information such as user ID, date and
time of failed attempts.
1.3.6.3 Audit trail information is
Loss of audit reliability.
4
managed as records in order to prevent
editing of audit logs.
Class Summary
11
1.4 DISPOSE OF RECORDS (FINAL) (Transfer or destroy)
1.4.1 The system identifies records
Staff time needed to
eligible for transfer or destruction based
5
identify eligible records.
on records retention schedules and
disposition instructions (i.e., the system
automatically detects when a record’s
retention period will pass, notifies the
Records Officer that the record is
eligible for disposition, and stipulates
whether the record is eligible for
transfer or destruction).
1.4.2 The system exports records and
Staff time needed to
4
metadata to be transferred (i.e., copy
extract and/or reformat
and subsequently remove them from
records.
the system) in a format acceptable for
transfer to NARA.
1.4.3 The system deletes records to be
Degradation of reliability of
5
destroyed so they cannot be physically
record keeping practices.
reconstructed or otherwise retrieved.
For Official Use Only
I-10
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.4.4 The system maintains a record of
Staff time to create and
all record transfers and destructions
4
maintain record of
and provides certifiable proof of transfer
transfers and destructions.
or destruction. All records of transfer or
destruction are treated as records.
Class Summary
18
1.5
PROCESS RECORDS CONTAINING RESTRICTED OR NATIONAL SECURITY CLASSIFIED DATA
1.5.1 The system captures National
Loss of pertinent
Security Classification metadata for
information.
5
classified records. These metadata
elements include current classification,
reason for (authority), classification
source, derivative source (if any),
declassification date, downgrade
instructions, review date, reviewer,
declassification date, and declassifier.
1.5.2 For derivatively classified records,
Loss of pertinent
the system supports the capability to
4
information.
capture multiple reasons [“Reason(s)
for Classification”] and multiple sources
(“Classified By”) metadata elements.
1.5.3 The system provides a method for
Loss of control on
assigning classification levels to records
4
classified material.
(e.g., through a data or metadata field).
The classification levels should include,
but not be limited to: Confidential,
Secret, Top Secret, and No Marking.
1.5.4 Authorized users can make
Loss of control on
changes to the retention period before
3
classified material.
declassification.
[Note: Declassification
review occurs outside the system.]
Class Summary
16
For Official Use Only
I-11
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.6 INTERFACE WITH RMA (EXPORT RECORDS)
1.6.1 The system exports records and
Degradation of reliability of
5
history to the RMA.
record keeping practices.
1.6.2 The system exports metadata
Staff time to research data
4
attached to records to the RMA.
and manually add it to
RMA.
1.6.3 The system identifies and exports
Staff time to manually
4
associated (linked) records and
identify associated
maintains record relationships.
records, potential
incomplete
1.6.4 The system supports the
Staff time to research data
5
capability to add needed metadata
and manually add it to
when records are exported.
RMA.
1.6.5 The system maintains pointers to
Cannot ensure that
4
exported records (i.e., associated
records are disposed of
records in the system should be linked
properly.
to the exported record in the RMA).
When a record is transferred from one
system to another (the RMA), its
"location" changes. Any pointers that
pointed to the record in its "old location"
need to be modified to reflect its "new
location." For example, the system may
contain past versions of a document
(these versions may not be records, but
documents), and the latest version is
being transferred to a new RMA
[possibly from a document management
application (DMA)]. When a user opens
up an outdated version of that
document, the system should indicate
that the latest version is located in the
RMA.
For Official Use Only
I-12
Version 1.0
FBI Electronic Recordkeeping
Appendix I
Certification Manual
Risk Management
Risk
Compliance
Risk
Criterion
Adverse Effect
Comment
Baseline
Value
Score
1.6.6 Unique identifiers are transferred
Cannot ensure that
4
from source systems to the RMA (i.e.,
records are disposed of
the system sends the unique identifier
properly.
for a record from the original system to
the RMA when a record is transferred to
the RMA).
Class Summary
26
For Official Use Only
I-13
Version 1.0
FBI Electronic Recordkeeping
Appendix J
Certification Manual
Risk Management
Appendix J—ERK System Certification Report Template
Electronic Recordkeeping (ERK)
System Certification Report
<System Name>
<System Acronym>
[date]
Version
Federal Bureau of Investigation
935 Pennsylvania Avenue, NW
Washington, DC 20530
Prepared by Electronic Records Section Staff
[Name], Test Team Leader
Reviewed by [Reviewer’s Name]
For Official Use Only
J-1
Version 1.0
FBI Electronic Recordkeeping
Appendix J
Certification Manual
Risk Management
Table of Contents
1. Purpose of Document
2
2. Description of <System>
3
3. System Risk Assessment
3
3.1.
Summary of Criteria Evaluation Scores
3
3.2.
Declare Records
4
3.3.
Capture Records
4
3.4.
Maintain or Use Records
4
3.4.1. Records Organization
4
3.4.2. Records Security
4
3.4.3. Records Access
4
3.4.4. Records Retrieval
4
3.4.5. Records Preservation
4
3.4.6. Audit/Oversight
4
3.5.
Dispose of Records
4
3.6.
Process Records Containing Restricted or National Security Classified Data
4
3.7.
Interface with Records Management Application (RMA)
4
Appendix A: <System> ERK Compliance Evaluation Worksheet
List of Tables
Table 3-1. Compliance Evaluation Scores Summary
For Official Use Only
J-2
Version 1.0
FBI Electronic Recordkeeping
Appendix J
Certification Manual
Risk Management
1. Purpose of Document
[Describe the purpose of the document and provide a brief description of the system compliance
evaluation process. Sample text follows.]
The purpose of the ERK System Certification Report is to compile and convey the results of the
electronic recordkeeping certification
(ERKC) Validation process for the
<system name
(acronym)>. The Validation process consists of an evaluation of the system against FBI ERK
Assessment Criteria. The evaluation determines how well the characteristics of the system
satisfy the ERK criteria.
The criteria are listed in the ERK Compliance Evaluation Worksheet. Each criterion has a pre-
assigned Risk Baseline Value to denote how critical it is with regard to electronic recordkeeping.
If the system completely satisfies a criterion, the Compliance Value is 1 (i.e., 100 percent of the
Baseline Value). If the criterion is not completely satisfied by the characteristics of the system,
the Evaluator judges how close the system comes to satisfying the criterion and assigns a
decimal score ranging from 0 to 1, with 1 signifying 100 percent compliance. If the criterion is
not relevant to the system, the Evaluator assigns a Risk Baseline value of 1.
2. Description of <System>
[Provide a brief description of the system, including the system name, the FBI Section and
Division to which it belongs, its purpose, and a description of the records that it contains.]
3. System Risk Assessment
[Provide a general description or summary of the system’s compliance and non-compliance with
ERK criteria.]
3.1 Summary of Compliance Evaluation Scores
The following table summarizes the ERK Compliance Evaluation scores for <system> by criteria
class.
Table 3-1. Compliance Evaluation Scores Summary
Total Baseline Value
Criteria Class
Score
for the Class
Declare Records
14
Capture Records
6
Records Organization
30
Records Security
22
Records Access
11
Records Retrieval
10
Records Preservation
13
Audit/Oversight
11
For Official Use Only
J-3
Version 1.0
FBI Electronic Recordkeeping
Appendix J
Certification Manual
Risk Management
Total Baseline Value
Criteria Class
Score
for the Class
Dispose of Records
18
Process Records Containing Restricted or National
16
Security Classified Data
Interface with Records Management Application
26
Total Risk Score
177
[Highlight areas of exceptionally strong or poor compliance]
The following sections describe system non-compliance with ERK criteria. These descriptions
are organized by ERK criteria class. Appendix A of this System Certification Report provides
the completed ERK Compliance Evaluation Worksheet, which provides additional details of the
evaluation. For each instance of non-compliance, the following items are presented:
· Detailed description of non-compliance
· Recommendations to achieve compliance
· Potential consequences of non-compliance
· Mitigating circumstances, if any
3.2 Declare Records
3.3 Capture Records
3.4 Maintain or Use Records
3.4.1 Records Organization
3.4.2 Records Security
3.4.3 Records Access
3.4.4 Records Retrieval
3.4.5 Records Preservation
3.4.6 Audit/Oversight
3.5 Dispose of Records
3.6 Process Records Containing Restricted or National Security Classified Data
3.7 Interface with Records Management Application (RMA)
For Official Use Only
J-4
Version 1.0
FBI Electronic Recordkeeping
Appendix J
Certification Manual
Risk Management
Appendix A: ERK Compliance Evaluation Worksheet
<insert Worksheet>
For Official Use Only
J-5
Version 1.0
FBI Electronic Recordkeeping
Appendix K
Certification Manual
Risk Management
Appendix K—ERK Certification Letter Template
U.S. Department of Justice
Federal Bureau of Investigation
Washington, DC 20535-0001
<Date>
<Name>
AD, <System Owner division>
Federal Bureau of Investigation
Room
Washington, DC 20535
Dear (name):
The purpose of this communication is to certify the <named information system (acronym)> to
be in compliance with the electronic recordkeeping. The Records Management Division has
completed the review of the ERK System Certification Report dated <date> and received <date>.
The FBI Records Officer, in conjunction with the Records Management Division, has
determined that the system [is approved to operate.] [has an interim approval to operate. The
interim approval to operate is contingent on the action items being achieved within the next 180
days.]
The Records Management Division evaluated the <system acronym> for compliance with
regulations from the National Archives and Records Administration (NARA), in concert with
FBI policy. Certification is granted for the period of three years or until major changes affecting
the records profile of the system are made. The ERK certification is in effect from <date> to
<date>.
CERTIFICATION STATEM ENT FOR
<NAMED INFORMATION SYSTEM (ACRONYM)>
Sincerely,
Robert Garrity
FBI Records Officer
Case ID#:
For Official Use Only
K-1
Version 1.0
FBI Electronic Recordkeeping
Appendix L
Certification Manual
Risk Management
Appendix L—Sample ERKC Electronic Communication
Template
Electronic Recordkeeping Certification Electronic Communication (EC)
FEDERAL BUREAU OF INVESTIGATION
Precedence: Routine
Date:
To: System Owner Division
Attn: AD, System Owne r Division
POC(s) System Owner Division
Records Management Division
Attn: AD, Records Management Division
AD, Information Resources Division
From: Records Management Division
Contact: Michael L. Miller, <ext #>
Approved By: Robert Garrity,
Drafted By:
<name>
Case ID #:
Title: CREDITATION - RECOMMENDATION FOR ERK CERTIFICATION OF THE
NAMED INFORMATION SYSTEM (ACRONYM)
Synopsis: To notify the System Owner of the certification of the of the <names information
system (acronym)> [and address outstanding items].
Reference: <number> Serial No. (Certification EC)
Details: The Records Management Division has completed the review of the <system’s
acronym> ERK Compliance Evaluation Report dated <date> and received <date>. Resulting
from this revie w, the Records Management Division has recommended that the <system
acronym> be ERK certified from <date> to <date>.
[The <system acronym> certification is contingent on [list vulnerabilities and required actions]
to be completed within 180 days. Maintaining a current certification is also subject to the
continued adherence to the provisions of ERK certification criteria.]
LEADS:
Set Lead 1: (Action)
System Owner Division at Washington, DC
Develop and implement [required corrective actions] within 180 days.
For Official Use Only
L-1
Version 1.0
FBI Electronic Recordkeeping
Appendix M
Certification Manual
Risk Management
Appendix M—FBI RMA Metadata List
Element
Definition/Descriptions
Individual Documents
Unique RMA Identifier
An unambiguous system-generated data element that identifies a
particular record.
Contributor Record ID
Unique ID provided by the Contributing System which identifies a
particular record within that system.
File Number
Identifies the classification, sub-classification (alpha), Office of
Origin, and Case number.
Serial
Number assigned to the document within the Case ID.
Document Type
Code indicating the type of document.
“TYPE”
Document Date
Generally the date appearing on the face of the document. In the
case of e-mail, it is date sent.
To / Addressee
The recipient(s) of the document.
From / Author - Individual
The originator of the document. The individual who creates, sends,
signs the document.
From / Author - Organization
The organization to which the originator of the document belongs.
Title / Subject / Topic of
Generally the “name” of the document (e.g., the title of an EC or
Document
memorandum, the subject line of an e-mail, the title of a report,
briefing, spreadsheet, etc.)
Description / Abstract / Notes
A brief narrative description about the record, which usually
contains keywords.
National Security Classification
Identifies the classification level for the security classification. The
document classification reflects the highest classification in the
document.
Other Restrictions
Identifies a record to which a legislative or regulatory restriction has
been applied (i.e., Rule 6(e), FOIA, litigation matters).
Record Status
Indicates the distinction between the official record, a copy,
duplicates, etc. The default would be Records. Generally inherited
from the file classification or file number.
Document Disposition
Those actions taken regarding Federal records after they are no
longer required to conduct current Agency business. Generally
inherited from the file classification or file number.
File Classification Disposition
The disposition assigned to the file classification number. Can be
permanent, disposable, sample/select - undetermined,
sample/select - permanent, sample/select - disposable, or
unscheduled.
Selection Criteria
If the disposition is sample/select - permanent, this identifies the
criterion/criteria used to make that determination.
Records Schedule Identification
Identification of the approved disposition authority. Generally linked
from the file classification.
Entry Date
The date the record was entered into the system.
Batch Documents (Managed at the file level or higher)
Individually Entered Data Elements
File Number
Identifies the classification, sub-classification (alpha), Office of
Origin, and Case number
Volume Number / Sub-part of the
Identifies the location of the record within the sub-sets of a physical
Case File
case file.
For Official Use Only
M-1
Version 1.0
FBI Electronic Recordkeeping
Appendix M
Certification Manual
Risk Management
Batch Generated Data Elements
Record Status
Indicates the distinction between the official record, a copy,
duplicates, etc. The default would be Records.
Document Disposition
Those actions taken regarding Federal records after they are no
longer required to conduct current Agency business. Generally
inherited from the file classification or file number.
File Classification Disposition
The disposition assigned to the file classification number. Can be
permanent, disposable, sample/select - undetermined,
sample/select - permanent, sample/select - disposable, or
unscheduled.
Selection Criteria
If the disposition is sample/select - permanent, this identifies the
criterion/criteria used to make that determination.
Retention
The length of time that a record must be kept before it is destroyed,
which is determined by scheduling.
National Security Classification
Identifies the classification level for the security classification. The
document classification reflects the highest classification in the
document.
Other Restriction
Identifies a document to which a legislative or regulatory restriction
has been applied, (i.e., Rule 6(e), FOIA, litigation matters).
Scanning Project ID
Identifies the title of the Scanning Project.
System Generated Data Elements
Unique RMA Identifier
An unambiguous system-generated data element that identifies a
particular record.
Entry Date
The date the record was entered into the system.
For Official Use Only
M-2
Version 1.0
ARMY, MARINE CORPS, NAVY, AIR FORCE
KILL BOX
MULTI-SERVICE TACTICS,
TECHNIQUES, AND
PROCEDURES FOR
KILL BOX EMPLOYMENT
FM 3-09.34
MCRP 3-25H
NTTP 3-09.2.1
AFTTP 3-2.59
August 2009
AIR LAND SEA
APPLICATION
DISTRIBUTION RESTRICTION: Distribution authorized to DOD
and DOD contractors only to protect technical or operational
CENTER
information from automatic dissemination under the International
Exchange Program or by other means. This protection applies to
publications required solely for official use and to those containing
valuable technical or operational information. This determination
was made on 11 July 2008. Other requests will be referred to:
HQ TRADOC, ATTN: ATFC-EJ, Ft Monroe, VA 23651-1067; HQ
MCCDC, ATTN: C116, Quantico, VA 22134-5021; NWDC, ATTN:
N5, Norfolk, VA 23511-2723; and LeMay Center for Doctrine
Development and Education, ATTN: DDJ, Maxwell AFB,
36112-6112.
DESTRUCTION NOTICE: Destroy by any method that must
prevent disclosure of contents or reconstruction of the document.
MULTI-SERVICE TACTICS, TECHNIQUES, AND PROCEDURES
FOREWORD
This publication has been prepared under our direction for use by our respective
commands and other commands as appropriate.
JOSEPH E. MARTZ
W.L. MILLER, JR.
Brigadier General, US Army
Brigadier General, US Marine Corps
Deputy Director/Chief of Staff,
Director
Army Capabilities Integration Center
Capabilities Development Directorate
WENDI B. CARPENTER
STEPHEN J. MILLER
Rear Admiral, US Navy
Major General, US Air Force
Commander
Commander
Navy Warfare Development Command
Curtis E. LeMay Center for Doctrine
Development and Education
This publication is available through the ALSA Web site
the Air Force at the Air Force Publishing Web site
PREFACE
1. Purpose
This publication provides a single source multi-Service tactics, techniques, and
procedures (MTTP) publication that focuses on conducting kill box operations at the
operational and tactical levels of warfighting in order to facilitate the expeditious air-
to-surface lethal attack of targets which may be augmented by or integrated with
surface-to-surface indirect fires.
2. Scope
This publication is designed for use at the operational and tactical levels for training,
planning, and conducting kill box operations. This MTTP outlines multi-Service kill
box planning procedures, coordination requirements, employment methods, and
command and control responsibilities. It is consistent with joint doctrine and
provides principles that can assist planners to coordinate, deconflict, synchronize,
and implement kill box procedures among the components assigned to a joint force.
This publication has worldwide application and is intended to supplement Joint
Publication (JP) 3-09, Joint Fire Support.
3. Applicability
This publication provides the joint force commander (JFC) and Service components
unclassified kill box MTTP. The target audience includes commanders, the
operations section (current operations, fires, and future plans), and the intelligence
section of Service components, and their main subordinate elements (i.e., Army
corps, Marine expeditionary force, Navy numbered fleet, and Air Expeditionary Task
Force) and their counterparts on the JFC’s staff.
4. Implementation Plan
Participating Service command offices of primary responsibility will review this
publication, validate the information and, where appropriate, reference and
incorporate it in Service manuals, regulations, and curricula as follows:
Army. Upon approval and authentication, this publication incorporates the
procedures contained herein into the United States (US) Army Doctrine and Training
Literature Program as directed by the Commander, US Army Training and Doctrine
Command (TRADOC). Distribution is in accordance with applicable directives listed
on the authentication page.
Marine Corps.1 The Marine Corps will incorporate the procedures in this
publication in US Marine Corps training and doctrine publications as directed by the
Commanding General, US Marine Corps Combat Development Command
(MCCDC). Distribution is in accordance with the Marine Corps Publication
Distribution System.
1 Marine Corps PCN: 144 000160 00
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
i
Navy. The Navy will incorporate these procedures in US Navy training and
doctrine publications as directed by the Commander, Navy Warfare Development
Command (NWDC)[N5]. Distribution is in accordance with Military Standard
Requisition and Issue Procedure Desk Guide (MILSTRIP Desk Guide) Navy
Supplement Publication-409 (NAVSUP P-409).
Air Force. The Air Force will incorporate the procedures in this publication in
accordance with applicable governing directives. Distribution is in accordance with
Air Force instruction (AFI) 33-360.
5. User Information
a. TRADOC, MCCDC, NWDC, Curtis E. LeMay Center for Doctrine Development
and Education (LeMay Center), and the Air Land Sea Application (ALSA) Center
developed this publication with the joint participation of the approving Service
commands. ALSA will review and update this publication as necessary.
b. This publication reflects current joint and Service doctrine, command and control
organizations, facilities, personnel, responsibilities, and procedures. Changes in
Service protocol, appropriately reflected in joint and Service publications, will
likewise be incorporated in revisions to this document.
c. We encourage recommended changes for improving this publication. Key your
comments to the specific page and paragraph and provide a rationale for each
recommendation. Send comments and recommendations directly to—
ii
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
Army
Commander, US Army Training and Doctrine Command
ATTN: ATFC-EJ
Fort Monroe VA 23651-1067
DSN 680-3951 COMM (757) 788-3951
E-mail: doctrine.monroe@us.army.mil
Marine Corps
Deputy Commandant for Combat Development and Integration
ATTN: C116
3300 Russell Road, Suite 204
Quantico VA 22134-5021
E-mail: Publication POC at https://www.doctrine.usmc.mil
Navy
Commander, Navy Warfare Development Command
ATTN: N5
1530 Gilbert Street, Suite 2128
Norfolk, VA 23511-2723
DSN 948-1070/4201 COMM (401) 841-1070/4201
E-mail: alsapubs@nwdc.navy.mil
Air Force
Commander, Curtis E. LeMay Center for Doctrine Development and Education
ATTN: DDJ
115 North Twining Street
Maxwell AFB AL 36112-6112
DSN 493-2640/2256 COMM (334)953-2640/2256
E-mail: lemayctr.ddj.workflow@maxwell.af.mil
ALSA
Director, ALSA Center
114 Andrews Street
Langley AFB VA 23665-2785
DSN 575-0902 COMM (757) 225-0902
E-mail: alsa.director@langley.af.mil
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
iii
SUMMARY OF CHANGES
The following is a summary of changes for FM 3-09.34/MCRP 3-25H/NTTP 3-09.2.1/
AFTTP 3-2.59, Multi-Service Tactics, Techniques, and Procedures for Kill Box
Employment.
This revision presents new and updated material to the reader. The organization of
the publication has been changed to: Chapter I - Overview; Chapter II - Command
and Control Responsibilities; Chapter III - Planning; Chapter IV - Execution;
Appendix A - Immediate Kill Box Decision Flow Charts; and Appendix B - Kill Box
Coordination Vignettes.
In addition, this revision:
• Adds a new chapter explaining command and control responsibilities.
• Expands the planning chapter to include graphical descriptions of the kill box
planning process and its relationship to the joint targeting process.
• Describes the execution process to include strike coordination and
reconnaissance (SCAR).
• Removes three appendices because they referenced tactics, techniques, and
procedures no longer in practice: Example Procedures for Establishing Kill
Boxes, Theater-Specific Kill Box Procedures, and the Common Geographic
Reference System.
iv
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
*FM 3-09.34
MCRP 3-25H
NTTP 3-09.2.1
AFTTP 3-2.59
*FM 3-09.34
US Army Training and Doctrine Command
Fort Monroe, Virginia
MCRP 3-25H
Marine Corps Combat Development Command
Quantico, Virginia
NTTP 3-09.2.1
Navy Warfare Development Command
Norfolk, Virginia
AFTTP 3-2.59
Curtis E. LeMay Center for Doctrine
Development and Education
Maxwell Air Force Base, Alabama
4 AUGUST 2009
KILL BOX
MULTI-SERVICE TACTICS, TECHNIQUES, AND PROCEDURES FOR
KILL BOX EMPLOYMENT
EXECUTIVE SUMMARY
vii
Chapter I OVERVIEW
1
1. DEFINITION AND PURPOSE
1
2. ESTABLISHMENT
1
3. EMPLOYMENT
2
4. CONSIDERATIONS
3
5. GRAPHIC PORTRAYAL
4
Chapter II COMMAND AND CONTROL RESPONSIBILITIES
5
1. GENERAL
5
2. JOINT FORCE COMMANDER
6
3. JOINT FORCE LAND COMPONENT COMMANDER
7
4. JOINT FORCE MARITIME COMPONENT COMMANDER
8
5. JOINT FORCE AIR COMPONENT COMMANDER
9
6. JOINT FORCE SPECIAL OPERATIONS COMPONENT COMMANDER
10
DISTRIBUTION RESTRICTION: Distribution authorized to DOD and DOD contractors only to protect technical or operational
information from automatic dissemination under the International Exchange Program or by other means. This protection
applies to publications required solely for official use and to those containing valuable technical or operational information. This
determination was made on 11 July 2008. Other requests will be referred to:
HQ TRADOC, ATTN: ATFC-EJ, Ft Monroe, VA 23651-1067;
HQ MCCDC, ATTN: C116, Quantico, VA 22134-5021;
NWDC, ATTN: N5, Norfolk, VA 23511-2723;
and LeMay Center for Doctrine Development and Education, ATTN: DDJ, Maxwell AFB, 36112-6112.
DESTRUCTION NOTICE: Destroy by any method that must prevent disclosure of contents or reconstruction of the document.
*This publication supersedes FM 3-09.34, MCRP 3-25H, NTTP 3-09.2.1, AFTTP(I) 3-2.59, 13 June 2005.
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
v
CHAPTER III PLANNING
11
1. GENERAL
11
2. KILL BOX TYPES
11
3. KILL BOX TERMINOLOGY
13
4. PLANNING CONSIDERATIONS
14
5. KILL BOX PLANNING PROCESS
16
CHAPTER IV EXECUTION
23
1. EXECUTION OF OPERATIONS WITHIN KILL BOXES
23
2. KILL BOX ENTRY/EXIT
23
3. COORDINATION WITHIN AN ACTIVE KILL BOX
25
4. TARGET ENGAGEMENT
27
APPENDIX A IMMEDIATE KILL BOX DECISION FLOW CHARTS
29
1. JOINT FORCE AIR COMPONENT COMMANDER REQUESTING IMMEDIATE KILL BOX
30
2. ARMY MANEUVER UNIT REQUESTING IMMEDIATE KILL BOX
32
3. MARINE AIR-GROUND TASK FORCE GROUND COMBAT ELEMENT REQUESTING IMMEDIATE KILL BOX
34
4. JOINT FORCE MARITIME COMPONENT COMMANDER REQUESTING AN IMMEDIATE KILL BOX
36
APPENDIX B KILL BOX COORDINATION VIGNETTES
39
1. JFLCC NOMINATED BLUE KILL BOX INSIDE THE JFLCC’S AO
39
2. JFACC NOMINATED BLUE KILL BOX OUTSIDE THE JFLCC’S AO
41
3. JFMCC NOMINATED PURPLE KILL BOX INSIDE THE JFLCC’S AO
43
4. JFLCC NOMINATED PURPLE KILL BOX INSIDE THE JFLCC’S AO
45
5. JFSOCC NOMINATED PURPLE KILL BOX OUTSIDE THE JFLCC’S AO
47
REFERENCES
49
GLOSSARY
51
List of Figures
Figure 1. Blue Kill Box Graphic Portrayal
4
Figure 2. Blue Kill Box
12
Figure 3. Purple Kill Box
13
Figure 4. Kill Box Development Correlation
17
Figure 5. Planned Kill Box Development
18
Figure 6. Kill Box Request Format
19
Figure 7. Dynamic Targeting Steps
21
Figure 8. C2 Agency Briefing
24
Figure 9. Kill Box Check-in Briefing
27
Figure 10. Kill Box Attack Briefing
28
Figure 11. JFACC Decision Flow Chart
30
Figure 12. Army Maneuver Unit Decision Flow Chart
32
Figure 13. MAGTF Decision Flow Chart
34
Figure 14. JFMCC Decision Flow Chart
36
List of Tables
Table 1. Kill Box Responsibilities Matrix
5
vi
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
EXECUTIVE SUMMARY
KILL BOX
Multi-Service Tactics, Techniques, and Procedures for
Kill Box Employment
The Kill Box MTTP reinforces kill boxes as three-dimensional areas used to facilitate
the integration of joint fires while also being a permissive fire support coordination
measure (FSCM) in accordance with JP 3-09, Joint Fire Support. The publication
offers a detailed explanation of kill box employment and provides information to
effectively organize, plan, and execute kill box procedures.
The purpose of this publication is to provide planners and operators with a single
source MTTP manual that focuses on employment of kill boxes at the operational
and tactical levels of warfighting to facilitate the expeditious air-to-surface lethal
attack of targets which may be augmented by or integrated with surface-to-surface
indirect fires. The target audience includes commanders, operations and
intelligence sections of Service components, and their counterparts on the JFC’s
staff.
Chapter I Overview
Chapter I provides the definition of a kill box and briefly describes the purpose,
employment, and overarching concepts concerning kill boxes. It provides a graphic
portrayal of these concepts and defines unique kill box terms used in the document.
Chapter II Command and Control Responsibilities
Chapter II outlines command and control duties, establishing authority, control of
assets, and coordination/deconfliction responsibilities.
Chapter III Planning
Chapter III provides an overview of kill box planning and coordinating
considerations. It also details the kill box establishment process and describes the
characteristics of the two types of kill boxes: the blue kill box which permits air-to-
surface fires and the purple kill box which permits integration of surface-to-surface
indirect fires with air-to-surface fires.
Chapter IV Execution
Chapter IV describes factors and procedures involved in conducting kill box
operations, such as SCAR.
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
vii
PROGRAM PARTICIPANTS
The following commanders and agencies participated in this publication:
Army
US Army Training and Doctrine Command, Army Capabilities Integration Center,
Fort Monroe, VA
US Army Training and Doctrine Command, Futures Center, JADD, Fort Monroe, VA
US Army Training and Doctrine Command, Combined Arms Center, CADD,
Fort Leavenworth, KS
US Army Field Artillery School, DOTD, Fort Sill, OK
US Army Air Defense School, Fort Bliss, TX
Navy
Navy Warfare Development Command, Norfolk, VA
Naval Strike and Air Warfare Center, Fallon, NV
Strike Fighter Weapons School, Atlantic, NAS Oceana, VA
Hawkeye Weapons and Tactics Unit Atlantic, Norfolk, VA
Marine Corps
Marine Corps Combat Development Command, Quantico, VA
Marine Aviation Weapons and Tactics Squadron-1, Yuma, AZ
II Marine Expeditionary Force/G-3, Camp Lejune, NC
Air Force
Curtis E. LeMay Center for Doctrine Development and Education, Maxwell, AFB, AL
HQ Air Combat Command/DOTW, Langley AFB, VA
HQ Pacific Air Forces/A3OW, Hickam AFB, HI
57th Operations Group, Nellis AFB, NV
505th Command and Control Wing, Hurlburt Field, FL
607th Air and Space Operations Center, Osan AB, Republic of Korea
viii
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
Chapter I
OVERVIEW
1.
Definition and Purpose
a. Definition: A kill box is a three-dimensional area used to facilitate the
integration of joint fires. It is a permissive FSCM as described in JP 3-09, Joint
Fire Support.
b. Purpose: When established, the primary purpose of a kill box is to allow lethal
attack against surface targets without further coordination with the establishing
commander and without terminal attack control. When used to integrate air-to-
surface and surface-to-surface indirect fires, the kill box will have appropriate
restrictions. The goal is to reduce the coordination required to fulfill support
requirements with maximum flexibility while preventing fratricide.
Note: All aircrew conducting air interdiction within the confines of a kill box will
execute their mission in accordance with rules of engagement (ROE) and special
instructions (SPINS) applicable to air interdiction.
2.
Establishment
a. Supported component commanders, acting on JFC authority, establish and
adjust kill boxes in consultation with superior, subordinate, supporting, and
affected commanders. Requirements for kill boxes and other control measures
are determined using normal component targeting and planning processes and
are established and approved by commanders or their designated staff
(e.g., G-3, fire support coordinator [FSCOORD]). Information about the type,
effective time, duration, and other attributes will be published and disseminated
using existing voice and digital command and control (C2) systems. Kill boxes
should be canceled when no longer needed.
b. There are two types of kill boxes: blue and purple. Chapter 3 provides further
details.
(1) Blue Kill Box. A blue kill box permits air interdiction in the kill box without
further coordination from the establishing headquarters (HQ).
(2) Purple Kill Box. A purple kill box permits air interdiction in the kill box
without further coordination from the establishing HQ while allowing land and
maritime component commanders to employ surface-to-surface indirect fires.
The end state is maximum use of joint fires within the kill box to create
synergistic effects with maximum potential for engaging targets.
c. Kill box characteristics:
(1) Target Area. The location and size of the kill box are determined by the
expected or known location of targets in a specified area. The dimensions of
a kill box are normally defined using an area reference system (i.e., Global
Area Reference System [GARS]) but could follow well defined terrain features
or be located by grid coordinates or by a radius from a center point. The
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
1
standard dimensions using GARS would be a cell (30 minute (min) by 30 min
[approximately (approx) 44 kilometer (km) by 44km] area), quadrant (15 min
by 15 min [approx 22km by 22km] area), or keypad (5 min by 5 min [approx
7.5km by 7.5km] area). Reference JP 2-03, Geospatial Intelligence Support
to Joint Operations, for further information concerning GARS.
(2) Airspace. The airspace block located above the kill box target area is
protected and extends from the surface (or coordinating altitude if
established) up to a ceiling established by the airspace control authority. The
airspace for a purple kill box includes a floor and a ceiling to enable
separation between aircraft delivering air-to-surface fires, trajectories of
surface-to-surface indirect fires, surface-to-air fires, and other aircraft. The
height of the ceiling should be established in the Airspace Control Plan
(ACP), Airspace Control Order (ACO), or SPINS to permit standardized
planning for other airspace uses. These parameters are developed by
coordination between fire support and airspace organizations.
3.
Employment
a. Kill boxes are normally used when a support relationship already exists
between two or more functional or Service components and a theater-specific
concept of operations (CONOPS) has been established for the integration and
deconfliction of fires and airspace. The goal is to reduce the coordination
required to fulfill support requirements with maximum flexibility while preventing
fratricide.
b. Kill boxes support the commander’s objectives and CONOPS. As such, all
target engagements within a kill box must adhere to the establishing
commander’s scheme of maneuver and designated target priorities, effects, and
timing of fires.
c. A kill box will not be established for close air support (CAS) missions. If a
CAS mission is required within an established kill box, the portion of the kill box
requiring detailed integration should be closed.
d. C2 updates on kill boxes (e.g., altitude restrictions, frequency use, and control
measures within the kill box) are accomplished via appropriate C2 systems.
e. The establishment of a kill box is usually in support of a targeting decision.
The kill box assists target engagement by identifying the area where effects are
desired. Opening a kill box facilitates the targeting process described in JP 3-60,
Joint Targeting, but does not replace the requirement for intelligence,
surveillance, and reconnaissance (ISR) or for assigning assets to attack targets.
These actions are conducted within the standard joint and Service targeting
cycles in conjunction with the air tasking cycle.
f. Kill boxes can augment traditional FSCMs, such as fire support coordination
lines (FSCLs), coordinated fire lines (CFLs), and battlefield coordination lines
(BCLs). They also help the commander focus the effort of air interdiction and
indirect fire assets.
2
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
4.
Considerations
a. The JFC or establishing commander makes the decision to use a kill box and
determines size, location, and timing based on careful consideration of the
situation and CONOPS. Other factors for the JFC to consider are: disposition of
enemy/friendly forces, anticipated rates of movement, surface-to-surface indirect
weapons capabilities, concept and tempo of the operation.
b. FSCMs are not mutually exclusive so a kill box could contain other measures
within its boundaries to include: no-fire areas (NFAs), restricted operations area
(ROA)/restricted operations zone, or airspace coordination areas (ACAs).
Restrictive FSCMs and airspace coordinating measures (ACMs) will always have
priority when established in a kill box.
c. Optimally, there should be no friendly ground forces within or maneuvering
into an established kill box. If circumstances require otherwise (e.g., long-range
reconnaissance patrols, special operations forces (SOF) teams), then NFAs must
be established to cover those forces or the kill box must be cancelled. The
establishing commander must maintain awareness on locations of friendly
ground forces and the status of kill boxes within the operational area and
maintain timely kill box management to prevent fratricide.
d. Kill Box Coordinator (KBC). A KBC is assigned per kill box to: deconflict
aircraft; manage/direct effective target engagement; and provide battle damage
assessment. See chapter 4 for detailed information concerning kill box
coordination.
e. All aircraft not assigned to an active kill box are restricted from flying through
or delivering air-to-surface munitions into the kill box unless coordinated with the
KBC. Effects and trajectories of surface-to-surface indirect fires also are not
allowed, without coordination, to pass through the airspace of an active kill box.
Commanders facilitate coordination through their appropriate fire support
personnel and airspace organizations to deliver surface-to-surface indirect fires
into or through an established kill box.
f. Authority to engage is not automatically granted by the establishment of a kill
box; the kill box reduces and/or eliminates coordination with the establishing HQ
for mission accomplishment because all requirements for targeting guidance,
clearance of fires, and deconfliction with other ground assets are accomplished
in the process of establishing the kill box. Engagement authority is granted
through standard mission orders, but does not relieve aircrew of the responsibility
for complying with mission requirements such as designated target priority,
effects, and timing of fires; positive identification (PID); collateral damage
estimation (CDE); ROE; or SPINS.
g. Integration of air-to-surface fires and surface-to-surface indirect fires requires
application of appropriate restrictions: altitude, time, or lateral separation. The
establishing commander will determine which restrictions are appropriate for the
mission and ensure dissemination through the appropriate C2 nodes.
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
3
h. Surface-to-surface direct fires are not restricted by the establishment of a kill
box. However, it is important to recognize that in certain terrain, Army direct fire
guns, missiles, and rockets may be employed from high terrain and the gun-
target line of these weapons should be considered by aircraft operating in the kill
box.
5. Graphic Portrayal
a. A kill box is graphically portrayed by a solid black line defining the area
borders. The kill box will be listed as either a “BKB” (blue kill box) or a “PKB”
(purple kill box) and the commander will assign a measure number (001-999),
establishing HQ, and affected altitudes. In addition to the kill box name, a date-
time group (DTG) depicting the “established” and “cancelled” times for the kill box
must be included. The “established” and “cancelled” times may be written as on-
order. The unit identifier for the establishing HQ will be consistent with
designations in operation plans and operation orders (OPORDs). Units and/or
automation systems may add color to the boxes for visual recognition; however,
the basic graphic follows the standards of an FSCM. Kill box names will not be
used more than once. See figure 1 for an example of a joint force land
component commander (JFLCC) established blue kill box.
Figure 1. Blue Kill Box Graphic Portrayal
4
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
Chapter II
COMMAND AND CONTROL RESPONSIBILITIES
1.
General
a. Kill boxes are established to support the JFC’s CONOPS. The responsibility
for C2 of kill boxes, when delegated from the JFC, rests at the operational level
of command. Information exchange requirements and procedures for kill box
execution should be written into applicable orders during campaign planning to
ensure timely dissemination of kill box status.
b. Prior to planning for kill box employment, the JFC and his component
commanders must coordinate and agree on key theater/joint operations area
(JOA)-wide FSCM and ACM procedures including the use of long range fires,
fixed and rotary wing interdiction, and the location and phasing of current and
future JFLCC and joint force maritime component commander (JFMCC) area of
operations (AO). Component kill box interdiction must also be integrated with the
JFC’s theater/JOA-wide air interdiction effort.
c. Effective kill box interdiction operations require all participants to use standard
procedures across the JOA. Although there have been many advances in digital
C2 capabilities, C2 of aircraft operating in kill boxes will be predominantly
controlled by voice communications. Commanders should strive to limit required
coordination/communications with simple procedures that ensure consistency
across the JOA. See table 1.
Table 1. Kill Box Responsibilities Matrix
Blue or Purple Kill Box Location
Establishing Commander1
Component Coordination Requirements
Within unassigned areas of the
JFC
JFACC: No additional coordination required once
JOA
established.
JFACC (when delegated)2
Other components: Must coordinate with JFACC.
Purple kill box restrictions: Altitude, lateral, or time
separation as specified when established.
Within JFC-designated operational
JFLCC. JFMCC, or
JFACC: No additional coordination required once
areas
JFSOCC3
established, except changes in establishing commander
target priorities, effects, and timing.
Establishing HQ: Must notify the JFACC when
establishing, canceling, changing the dimensions of a kill
box or changing the establishing commander’s target
priorities, effects, and timing.
Other components: Must coordinate with establishing
HQ.
Purple kill box restrictions: Altitude, lateral, or time
separation as specified when established.
Notes: 1
The JFC may be the establishing commander for any FSCM within the operational environment.
2 The JFC will normally delegate to the JFACC the authority for establishing kill boxes in unassigned areas of the JOA.
3The JFSOCC is the establishing commander for kill boxes inside a joint special operations area.
JFC - joint force commander
AO-Area of Operations
JFACC - joint force air component commander
JFSOCC - joint force special operations component commander
JFLCC - joint force land component commander
JFMCC - joint force maritime commander
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
5
d. Kill box interdiction is not intended to replace existing procedures for CAS or
preplanned air interdiction against fixed targets. The option for kill box usage
rests with the supported commander during the theater/JOA-wide air interdiction
effort including JFLCC and JFMCC AO.
e. Service and joint procedures for coordination, clearance of fires, and
deconfliction described in documents such as JP 3-09, Joint Fire Support,
OPORDs, and SPINS apply across all components subordinate to the JFC.
2.
Joint Force Commander
a. Duties. The JFC develops guidance for kill box employment within the JOA.
Guidance is promulgated through JFC and component orders. The JFC also
directs the use of an area reference system (e.g., GARS).
b. Establishing Authority. The JFC normally delegates the component
commanders as the establishing authority for all kill boxes. A commander
establishing a kill box is responsible for coordinating and notifying all affected
commanders and forces.
(1) The JFC establishes supported and supporting relationships as outlined
in JP-1, Doctrine for the Armed Forces of the United States; and JP 3-0, Joint
Operations. These relationships tie directly to kill box establishing authority
through each phase. Commanders and designated supported commanders
with jurisdiction over the operational area where kill boxes are located have
the authority and responsibility to establish kill boxes within their assigned
areas.
(2) Once establishing authority is given to component commanders, the JFC
maintains visibility on all kill boxes within the JOA and adjudicates cross-
component coordination and establishment issues. In the case where the
JFC retains operational control of certain portions of the JOA, the JFC joint
fires element (JFE) controls the establishment of kill boxes within that
operational area.
c. Coordination and Deconfliction. The JFC designates command relationships
among the components in the operational environment. Within their AO, land
and maritime commanders are designated the supported commander for the
integration and synchronization of maneuver, fires, and interdiction. Accordingly,
land and maritime commanders designate the target priority, effects, and timing
of interdiction operations within their AO. Outside of those AOs, the JFC
normally designates the joint force air component commander (JFACC) as the
supported commander for interdiction within the JOA. A component supporting
another with fires must deconflict and integrate those fires with the supported
component. It is important that aircrews clearly understand the operational
environment they are operating in, who the supported commander is, and the
target priorities in the affected kill box.
d. Airspace Control Authority. The JFC accomplishes airspace control in the
operational area by designating the airspace control authority and defining the
relationship between the airspace control authority and component commanders.
6
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009
The airspace control authority is responsible for coordinating and integrating
airspace use within the JOA. The airspace control authority establishes an
airspace control system (ACS) that is responsive to the needs of the JFC,
integrates the ACS with the host nation, and coordinates/deconflicts user
requirements. The airspace control authority develops the ACP, and after JFC
approval, distributes it to all airspace users. The ACP is directive for all airspace
users to include manned and unmanned aircraft and indirect fires. The ACP is
further defined through the ACO, air tasking order (ATO) and SPINS. The
airspace control authority does not have the authority to approve, disapprove, or
deny combat operations. That authority is only vested in operational
commanders. However, the airspace control authority is responsible for all JOA
airspace control procedures which are approved by the JFC and are derived
entirely from JFC authority. The airspace control authority acts on behalf of the
JFC after approval of the ACP. If the airspace control authority and an affected
component commander are unable to obtain agreement on an airspace issue,
the issue will be referred to the JFC for resolution. Joint airspace control
provides the JFC operational flexibility to employ forces effectively throughout the
JOA.
e. Development and Distribution of Kill Box Procedures. Kill box employment
will affect both the execution of fires and airspace control throughout the JOA to
include the AO of the JFLCC and JFMCC. The JFC’s OPORD should outline the
broad kill box employment concept. The concept is further refined via
collaborative planning between the JFCs components and functional
commanders. Once defined, kill box procedures within the JOA must be
distributed by means of the JFC’s ACP; the JFACC’s ACO, ATO, SPINS, and
component OPORDs; and coalition releasable documents. Kill box procedures,
like all other procedures, must be reviewed as changes occur in the operational
environment and as operations transition from one phase to another in
accordance with (IAW) JP-5.0, Joint Operation Planning.
3.
Joint Force Land Component Commander
a. Duties. The JFLCC plans, coordinates, and employs kill boxes within a
scheme of maneuver consistent with the JFC’s intent. The land component may
vary in both size and capability based on the size and composition of the
deploying US Army and US Marine Corps (USMC) forces. The fires cell (FC)
designated by the JFLCC is the primary agency for planning, coordinating, and
establishing kill boxes.
b. Establishing Commander. The JFLCC exercises establishment authority as
delegated by the JFC.
c. Control of Assets. The JFLCC establishes kill boxes through his staff and
liaisons. The JFLCC uses the Army forces (ARFOR) FC or Marine Corps forces
(MARFOR) force fires coordination center (FFCC) to disseminate kill box
information to the battlefield coordination detachment (BCD) and/or component
liaisons. The following cells and liaisons have input and coordination
responsibilities to the primary staff with regard to kill box employment: air support
4 August 2009
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
7
operations center (ASOC)/tactical air control party (TACP), air liaison officer
(ALO), air and naval gunfire liaison company (ANGLICO), special operations
liaison element (SOLE), Marine liaison officer (MARLO), and the BCD. If
required, liaisons between the ARFOR and MARFOR will also be exchanged.
(1)
ARFOR
(a) Duties. The primary function of the ARFOR is to command and
control forces to meet the JFLCC’s and JFC’s intent. The FC within the
ARFOR is responsible for planning, coordinating, and publishing
procedures in component OPORDs/annexes, as well as employing kill
boxes in the ARFOR’s AO. This includes establishing kill boxes,
designating target priorities, effects, and timing of fires, and determining
interdiction tasks within the ARFOR’s AO.
(b) Establishing Commander. The ARFOR commander, designated by
the JFLCC or JFC as the AO commander, is the establishing authority for
kill boxes within that AO.
(c) Control of Assets. The commander’s FC and subordinate echelons,
in conjunction with assigned US Air Force (USAF) ASOC elements,
control/deconflict fires and aviation assets within kill boxes.
(2)
MARFOR
(a) Duties. The Marine air-ground task force (MAGTF) is the USMC’s
principal organization for all missions across the full range of military
operations. Within a Marine expeditionary force, the FFCC implements
the MAGTF commander’s intent. The FFCC within the MARFOR is
responsible for planning, coordinating, and publishing procedures in
component OPORDs/annexes, as well as employing kill boxes in the
MARFOR’s operational area. This includes establishing kill boxes;
designating target priorities, effects, and timing of fires; and determining
interdiction tasks within the MARFOR’s AO.
(b) Establishing Commander. The MARFOR commander, when
designated by the JFLCC or JFC as the AO commander, is the
establishing authority for kill boxes within that AO.
(c) Control of Assets. The commander’s FFCC and subordinate
echelons, in conjunction with the Marine air command and control system
(MACCS), controls/deconflicts fires and aviation assets within kill boxes.
4.
Joint Force Maritime Component Commander
a. Duties. When the JFC designates a JFMCC AO, the JFMCC is the supported
commander within the AO. As supported commander, the JFMCC is responsible
for planning, coordinating, and publishing procedures in component
OPORDs/annexes and employing kill boxes within the maritime operational area.
8
FM 3-09.34 / MCRP 3-25H / NTTP 3-09.2.1 / AFTTP 3-2.59
4 August 2009