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 -
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 -
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 -
PIPEDA
Inclusion of The Personal Information Protection and Electronic Documents Act (PIPEDA)
2 votes -
6 votes
-
3 votes
-
4 votes
-
4 votes
-
An easy way to determine exact number of CSF elements in the policy illustrative procedure
Assessors and assessed entities could benefit from something communicating the exact number of CSF implementation specifications present in the policy illustrative procedures. This could be through something like a number that precedes the policy illustrative procedure or even consistent use of roman numerals in the policy illustrative procedure. This would help everyone involved in preparing for, performing, and reviewing assessments ensure they are working with a generally understood denominator for scoring calculations.
For example:
Instead of saying "Inspect written policies to determine that they contain X, Y, and Z.", the policy illustrative procedure could display as,
"Inspect written policies to…14 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
-
2 votes
-
in v10: No requirements should dictate scope
In the requirement, "Risk designations are assigned for all positions in the organization", a scope of the whole organization is forced through the wording. In v10, no requirements should dictate scope in and of themselves and should instead be written in such a way that they can be tested to the assessment's scope.
4 votes -
1 vote
-
1 vote
-
2 votes
- Don't see your idea?