26 results found
-
HITRUST r2 alignment to DoD Zero Trust Strategy
HITRUST r2 alignment to DoD Zero Trust Strategy
https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-ZTStrategy.pdf
1 vote -
HITRUST r2 alignment to NYDFS - 23 NYCRR Part 500
HITRUST r2 alignment to NYDFS - 23 NYCRR Part 500
1 vote -
All requirements should be contained within the requirement statement
Requirements which must be met by implemented controls or processes should be entirely contained within the requirement statement. Additional requirements should not be introduced in illustrative procedures.
1 voteThanks for your idea submission! This is what we'll be doing for the next major CSF release.
-
2 votes
-
Adjust Wording in Task Under Domain 18
Type: Organizational . Level: 1 . ID: 1828.08a1Organizational.12
Missing word in policy portion under Illustrated Procedures: "Computers that store or process covered information are located in areas that are unattended and have unrestricted access by the public."
Adjusted sentence would be "Computers that store or process covered information are never located in areas..."
1 vote -
PIPEDA
Inclusion of The Personal Information Protection and Electronic Documents Act (PIPEDA)
2 votes -
1 vote
-
Each requirement statement should address only one idea, and each idea should be addressed by only one requirement statement
In many information security, privacy, and financial auditing approaches, the audited customer needs to produce one piece/set of evidence per requirement. Each requirement needs distinct artifacts. This allows for simple data management - my list of requirements is X long and therefore my list of evidence artifacts/sets should be the same length. I can then track progress as an audited customer by measuring how much evidence I have produced, and how much is left to go. I can even set up workflows within project management tools and GRC tools easily to accommodate this. Put in data terms - my requirement…
7 votes -
In v10, requirements focused on a single control maturity level should be avoided
Because we have a control maturity model that considers a written policy for each requirement, requirements focused on a single control maturity level should be avoided in v10. For example, the CSF currently contains some requirements about having a written policy, program, standard, guideline, etc. In those requirements, testing of both the "policy" and "implemented" control maturity levels are both test of a written policy (often the same one). Instead, requirements should be action-oriented (e.g. the org. does X) instead of policy oriented (e.g. the org. has a policy about X). Because of the control maturity model, the existence of…
9 votes -
Make all 44 authoritative sources into optional (selectable) regulatory factors
When setting up a new assessment, only a subset of the 44 authoritative sources in the CSF today are selectable / optional regulatory factors. Instead, 44 authoritative sources should be made into optional (selectable) regulatory factors.
2 votes -
3 votes
-
1 vote
-
3 votes
-
4 votes
-
6 votes
-
1 vote
-
4 votes
-
1 vote
-
2 votes
-
2 votes
- Don't see your idea?