Introduction

Section Explanation. Click to expand.

The product requirements document (PRD) is a central document used to align all stakeholders (product management, engineering, QA, designers, and leadership) on the overall objective and vision of the proposed product and is used as a decision-making tool.

When creating the PRD, provide just as much information as needed and nothing more. If the document is too long and complex, it will quickly become outdated, and readers will lose interest.

PRD content and structure vary by organization. Depending upon the product line, company culture, and processes, PRDs could have quite a different look and feel.

In this latest iteration of the Unified Compliance PRD template, we changed the template to help raise visibility of how the proposed product (or feature set) adheres to Unified Compliance’s strategic plan including details on why this product proposal is important to Unified Compliance.

Strategic Planning and Decision Making

Section Explanation. Click to expand.

Vision and Goal Setting: articulates the vision alignment, problem being addressed, and goals of the product proposal describing what the product is, who it is for, and how it will benefit the users and the organization.
Decision-Making Framework: helps in making informed decisions throughout the product development process acting as a reference point for evaluating progress and making changes.
Performance Measurement: sets the criteria for measuring the success of the product through specified metrics and key performance indicators (KPIs) including potential financial impact.
Basis for Prioritization: helps in prioritizing features based on the product strategy, market needs, and resource constraints.

Vision and Initiative Alignment

How does this proposal fit into our overall vision and which specific initiative does this proposal align with and how?

The UC Strategic Plan for 2024 has two foci:

content and
the sale of that content

This project squarely fits into the focus of bringing in additional content.

Content Ingestion Automation - ETL is a critical aspect of the initiative to “Partner with 3rd Party to Develop Automated Content Mapping”.

The automated content mapping comprises the complete end-to-end content capture, ETL, and mapping to the common controls. This particular product proposal is the “left-hand” side from capture to ETL.

The Problem

What problem are we trying to solve? and why it important to our customers and/or to Unified Compliance?

We currently rely on a team of expert mappers to meticulously add content into the UCF. The process works well but is slow. With the advent of automation and AI, Unified Compliance risks attacks from competitors who use technology to accelerate content acquisition.

We risk losing customers to other platforms if we fall behind on the extent of coverage.

We will also find it difficult to take on new market segments without automation.

High-level Approach

Briefly describe the approach you’re taking to solve this problem. Provide enough information for the reader to imagine possible solution directions and get a rough sense of the scope of this proposal.

The approach is to start with “left-hand” side (capture + ETL) of the automation process where compliance content is captured from a small set of compliance content providers.

Authority Documents, Citations, and Glossaries will be extracted from the content providers, transformed into the Common Data Format specification, and loaded into the UC platform. Automation tools and AI will be used to accelerate the end-to-end process with human assistance to review and approve critical steps in the process.

Once the process proven out, the intent is that it will be extended to many additional compliance content providers.

Goals

What does success look like? What metrics can we effect and why it is important to affect those metrics?

Goal	Metric	Why Important?
Reliably extract citations from Authority Documents	>= 80% accuracy where 20% of Citations need to be reworked (e.g., split, merged, rejected …)	If there is poor accuracy requiring extensive human correction, then there is little value.
Reliably extract glossaries from Authority Documents	100% accuracy	If there is poor accuracy requiring extensive human correction, then there is little value.
Reliably automate the end-to-end process of capturing, transforming, and loading STIG, NIST 800-53, FedRAMP, eCFR compliance content.		All four Authority Documents sources related to securing and hardening IT infrastructure for both the private and public sector. To provide value to customers with Security Operation's requirements, UC needs to maximize the breadth of IT security coverage to ensure we can provide security guidance for as many IT assets as possible.
Automate an end-to-end process to capture all STIG content.	All 457 STIGs, as Authority Documents, are available for customer consumption via API from the UC 4.0 API Gateway All Citations as part of the 457 STIGs are available for customer consumption via API from the UC 4.0 API Gateway All Glossaries with term-definition pairs as they related to the 457 STIGs are available for customer consumption via API from the UC 4.0 API Gateway	STIGs sit at the intersection of Sec Ops and GRC. Organizations need to harden their security posture with DoD approved security measures that are in alignment with the software and hardware vendors. IT departments will utilize a variety of software and hardware in their data centers. UC needs to maximize the breadth of STIG coverage to ensure we can provide security guidance for as many IT assets as possible.
Automate an end-to-end process to capture all NIST 800-53 content (approximately 36 files with a mixture of json, yaml, and xml documents), perform ETL, and load into the UCF in common data format.	All NIST-800-53 content, as Authority Documents, are available for customer consumption via API from the UC 4.0 API Gateway All Citations as part of the NIST-800-53 documents are available for customer consumption via API from the UC 4.0 API Gateway All Glossaries with term-definition pairs as they related to the NIST-800-53 content are available for customer consumption via API from the UC 4.0 API Gateway	NIST 800-53 helps IT departments implement proper security controls to proactively take care of their organization's infrastructure. As is the case with STIGs, the broader the coverage, will assist IT and security departments secure their security assets.
Automate an end-to-end process to capture all FedRAMP content (approximately 32 files with a mixture of json, yaml, and xml documents), perform ETL, and load into the UCF in common data format.	All FedRAMP content, as Authority Documents, are available for customer consumption via API from the UC 4.0 API Gateway All Citations as part of the NIST-800-53 documents are available for customer consumption via API from the UC 4.0 API Gateway All Glossaries with term-definition pairs as they related to the NIST-800-53 content are available for customer consumption via API from the UC 4.0 API Gateway	FedRAMP is a government-wide program that promotes the adoption of secure cloud services across the federal government by providing a standardized approach to security and risk assessment for cloud technologies and federal agencies. UC can assist federal agencies or organizations working with federal agencies to grow and use secure cloud technologies.

eCFR	…	…
New Customers
New Markets
Preparation for follow-on AI projects

Scope and Requirements

Section Explanation. Click to expand.

The intent of this section is for the following:

Scope Definition: defines the scope of the proposed product (or features), including what will and will not be included helping manage expectations and focus development efforts.

Guideline for Development: provides detailed information on the product’s features, functionalities, user flow, and interface to guide the development team in building the product.

Framework: provides high-level evaluation criteria for alternative solutions (build, buy, partner) to evaluate different routes to success.

Requirements

Describe the product requirements that will fulfill the underserved need(s).

Requirement	Importance	Comments
STIG Pipeline and Goal: All 457 STIGs, as Authority Documents, are available for customer consumption via API from the UC 4.0 API Gateway All Citations as part of the 457 STIGs are available for customer consumption via API from the UC 4.0 API Gateway All Glossaries with term-definition pairs as they related to the 457 STIGs are available for customer consumption via API from the UC 4.0 API Gateway
Scrape the STIG document library to download all zip files.	High	The zip files are multi-level nested zip files.
Unzip each STIG file to retrieve the XML files.	High
Store the XML files for later use.	High	The hierarchy of zip files must be maintained to ensure follow-on functions have context.
Identify which documents within the hierarchy are Authority Documents.	High	The zip files may contain readme’s or other files that do not constitute Authority Documents.
Identify which files are Glossary-specific.	High	Some files may solely be Glossaries with term-definition pair entries. Ensure those documents are also processed for follow-on steps.
Detect file metadata changes from prior processing.	High	Potential metadata changes could be a new document or a new version of an old document.
Only pass new or changed documents further down the pipeline.	High	No need to promote unchanged files. Question on what to do with depreciated documents in questions.
NIST 800-53 Pipeline and Goal: All NIST-800-53 content, as Authority Documents, are available for customer consumption via API from the UC 4.0 API Gateway All Citations as part of the NIST-800-53 documents are available for customer consumption via API from the UC 4.0 API Gateway All Glossaries with term-definition pairs as they related to the NIST-800-53 content are available for customer consumption via API from the UC 4.0 API Gateway
Access the GitHub repository for all NIST 800-53 content.	High
Retrieve and store the XML, JSON, and YAML files for later use.	High
Identify which documents are Authority Documents.	High
Identify which files are Glossary-specific.	High	Some files may solely be Glossaries with term-definition pair entries. Ensure those documents are also processed for follow-on steps.
Detect file metadata changes from prior processing.	High
Only pass new or changed documents further down the pipeline.	High
FedRAMP Data Pipeline and Goal: All FedRAMP content, as Authority Documents, are available for customer consumption via API from the UC 4.0 API Gateway All Citations as part of the NIST-800-53 documents are available for customer consumption via API from the UC 4.0 API Gateway All Glossaries with term-definition pairs as they related to the NIST-800-53 content are available for customer consumption via API from the UC 4.0 API Gateway
Access the GitHub repository for all FedRAMP content.
Retrieve and store the XML, JSON, and YAML files for later use.
Identify which documents are Authority Documents.
Identify which files are Glossary-specific.	High	Some files may solely be Glossaries with term-definition pair entries. Ensure those documents are also processed for follow-on steps.
Detect file metadata changes from prior processing.
Only pass new or changed documents further down the pipeline.
eCFR Data Pipeline and Goal: a b c
Access the eCFR files via the eCFR APIs.
Store files for later use.
Identify which documents are Authority Documents.
Identify which files are Glossary-specific.	High	Some files may solely be Glossaries with term-definition pair entries. Ensure those documents are also processed for follow-on steps.
Detect file metadata changes from prior processing.
Only pass new or changed documents further down the pipeline.		No need to pass along files with no changes.
General Pipeline (after initial source-specific tasks are completed, if possible)
Catalog each source Authority Document.	High	Gather all information as is required by the Common Data format.
Identify and extract Citations from the Authority Document	High	Citations are passages in the Authority Document that: contain Mandates (requirements) OR related contextual information such as stubs, informational, and informational gathering.
Maintain Citation structure.	High	Since Authority Documents will contain multiple Citations and passages may have related Citations, that structure must be maintained to know the relationship between Citations.
Extract Glossary from within Authority Documents.	High	Some Authority Documents may have glossary within the document. This will typically be near the end of the file. Extract the Glossary details including the Title, source, and all term-definition pairs.
Extract Glossary from glossary-specific files.	High	Some files may only have Glossary entries with term definition pairs. Extract the Glossary details including the Title, source, and all term-definition pairs.
Detect content changes from prior loads.	High	Nee discussion here. See questions section.
Transform the Authority Document into the Common Data Format	High	Use transformation documentation as reference as to how the source document schema structures are transformed into the Common Data Format.
Transform the Authority Document related Citations into the Common Data Format	High	As above, use the CDF transformation document as reference.
Transform the Glossaries into the Common Data Format	High	As above, use the CDF transformation document as reference.
Load Authority Documents into the Unified Compliance Platform	High	UCF engineering team will determine the optimal approach for loading (API, service, …)
Load Citations into the Unified Compliance Platform	High	Same as above
Load Glossaries into the Unified Compliance Platform	High	Same as above
Human Validation via a simple front-end
Since this is all back-end pipeline work with no customer interaction, the user experience needs to be good enough for us as “dog food”.
Allow human experts to view each Citation and relationships between Citations.	High
Allow human experts to approve or reject Citations.	High	Rejection reasons could include Citations that were improperly identified (e.g., it is not a mandate and/or does not include contextual information).
Allow human experts to approve or reject the entire Authority Document.	High	Rejection reasons could be if the entire document was extracted improperly (e.g., is not an authority document, no changes, too many citations are improperly identified …)
Allow human experts to change Citations.	High	What might they do here? Combine passages? Split out passages into other citations?
Automation and Monitoring
Produce logs for each step in the end-to-end process.
In the content capture step, capture the following statistical information: complete count of documents count of identified Authority Documents count of identified Glossaries. list of Authority Documents including name, location, change date, and metadata change value: same, new, updated, or deprecated. list of Glossaries including name, location, change date, and metadata change value: same, new, updated, or deprecated. count of ADs per metadata change value: same, new, updated, or deprecated. count of Glossaries per metadata change value: same, new, updated, or deprecated.
In the citation extraction step, capture the following statistical information per AD: Total count of citations extracted. Count of citations per type: requirement/mandate, stub, informational, and information gathering.
In the Glossary extraction step, capture the following statistical information per AD or Glossary: Total count of Glossaries extracted (assume will be 1) Total count of term-definition pairs extracted.
In the human validation step, capture the following statistical information per AD: Total count of ADs approved. Total count of ADs rejected. Total count of Citations approved. Total count of Citations rejected. Total count of Citations changed and by change type (split, merged, removed …).
In the transformation step, capture the following statistical information: Total count of ADs entering the process. Total count of ADs completing the process by TBD status (e.g., success vs. failure) Total count of Citations completing the process by TBD status (e.g., success vs. failure) Total count of Glossaries completing the process by TBD status (e.g., success vs. failure)
Allow for administrative monitor, start, and stop each step in the end to end process including: Content capture

Out of Scope / Future Functionality

List the known features that are out of scope for this project or might be revisited at a later time.

As is case with the assumptions, it is important to list these out so that architects and engineers can plan accordingly for these later updates.

Requirement	Comments
Tagging and Mapping STIGs, NIST, FedRAMP, or eCFR content to the Common Controls.	This project ends at the AD, Citation and Glossary extraction. Follow-on projects will include the mapping.
Human validation of the content capture	Later projects can include additional human validation. To get this project out quickly, steps such as metadata change detection can be reviewed and validated after the fact looking at logs and other information.
Human validation of the AD cataloging.	Same as above
Human validation of the transformation into the common data format	Same as above
Human validation of loading into the UCF	Same as above
No Corpora
No data lake

User Interaction and Design

Link to mockups, prototypes, or screenshots related to the requirements.

Process Flow Diagrams

Links to user journeys, process flow, or other diagrams related to the requirements.

Impacted Product Components

If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.

Open Questions

List any open questions that come to mind throughout the lifecycle of this initiative.

Question	Answer	Date Answered
What do we do with deprecated authority documents?
For STIGs, how do we identify which files are authority documents?
For NIST 800-53, how do we identify which files are authority documents?
For FedRAMP, how do we identify which files are authority documents?
For eCFRs, how do we identify which files are authority documents?
Specifically, what is required to catalog an AD?
In this first pass, what should constitute content changes? We don’t want to get too crazy and make this a massive project. Need to discuss.
How do we identify a citation that includes a mandate or related contextual information such as stubs, informational, and informational gathering?

Alternative Solutions

Provide a high-level evaluation criterion for alternative solutions (build, buy, partner) to evaluate different routes to success.

Milestones and Launch Checklist

Section Explanation. Click to expand.

The intent of this section is for the following:

Monetization: Financial impact this product will introduce (if any)

Risk Mitigation: Identifies potential risks and propose mitigation strategies.

Launch Readiness: launch checklist including high-level go-to-market plan to ensure cross-departmental alignment.

High-level Messaging: Includes Unique Selling Proposition (USP) raising visibility of the proposed solution’s value proposition.

High-level Messaging

What is the Unique Selling Proposition (USP)? Relay the key factors that separate our product from the competition and why we are the best possible solution for our prospects based on their unique needs.

Monetization

Will this product be part of an existing subscription or an add-on?

Will this product be usage based or part of a subscription?

Risk Mitigation

Identifies potential risks and propose mitigation strategies.

Risk	Mitigation Strategy

Launch Readiness

Identify any relevant milestones that people should now about. Will we “eat it” ourselves first? Will this require a beta? and what is the target launch date?

Date	Milestone	Audience	Description
TBD	Dogfood 🐶	Internal employees only.	Testing internally
TBD	Beta 🎈	Early cohort of X customers.	Getting user feedback
TBD	Public Launch 🚀	Roll-out to all users.	Let’s do it!

Launch Checklist

This section is a reminder to the product team to make sure all relevant stakeholders are involved as necessary.

Area	Question	Answer (yes/no)	Instructions if "Yes” (or unsure)
Customer Success	Will new training material be needed (or updates to existing classes)?	No	Talk to the Customer Success team.
Customer Success	Do we need a new or updated onboarding experience?	No	Talk to the Customer Success team.
Support	Will new FAQs be required (or updates to existing ones)? API documentation?	Yes	Talk to the Customer Support team.
Support	Will this functionality require new support processes like new HubSpot workflows or saved replies? Or training the support team on the product?	Yes	Talk to the Support team.
Growth & Data	Do we need additional tracking in order to measure success and impact on user behavior for the new feature? Will UserFlow be used? Do we need a new Power BI report?	Yes	Review within our Product Team
Growth & Data	Could this impact CTAs? Or new-user-experience (NUX)?	Yes	Review within our Product Team
Growth & Data	Are we turning this product or feature on for everyone immediately or are we going to use feature flags for a slow roll-out?	Everyone	Not applicable yet until feature flags are ready to go
Product	Are we running a Beta for this?	No	Review within our Product Team
Marketing	Are we introducing functionality where we will want to update or create new web pages? New/updated CTAs?	Yes	Talk with Marketing