您好Marcelo和Pau

非常感谢您的回答和贡献。

我喜欢Marcelo的建议，在结尾处带有数字后缀，因为当在项目开始时未考虑所有情况时，这将增加灵活性。 我也同意Pau的观点，即使用所有10个字符来传达尽可能多的信息将非常有用。

我看到了同一主题的另一篇文章：

https：//answers。 sap.com/questions/12123208/best-practice-for-mit-control-naming-convention.html

目前，我们正在处理SAP角色中的访问控制风险，我认为命名缓解控制的一种方法是：

缓解控制ID： <访问风险ID> _ << em>流代码> < 数字 后缀>

例如，如果我们对零售主数据业务流程（ZRMD1）中的关键操作具有自定义风险，并且希望减轻某些财务（FIN）角色中的此类风险，则缓解控制将为ZRMD1_FIN1。

谢谢

Reza Ahoui

嗨，波城。

我喜欢MIT_前缀，因为它为缓解控制带来了更多的视觉清晰度。 用户反馈总体上是积极的，因为当他们在其他ID（例如风险和功能）中看到该ID时，很快就会想到该ID的目的。 而且，由于我从来不需要使用10个字符作为控件ID，因此我可以使用此前缀"扔掉它们"，而不必将它们留空。

在我处理的场景中，控件无法面向功能。 （当然，对于这些概念重叠的"关键行动风险"除外）。 它们必须针对风险，甚至针对规则，并且同一功能的两个组合可能导致完全不同的控制。 老实说，我看不到将控件定位为函数的简便方法，因为在您拥有2个或3个函数的SoD风险中，这听起来很矛盾。

最后，我们在这里可以看到的是我一开始所说的。 控制措施的命名约定将与缓解策略紧密相关，而缓解策略又必须专注于业务需求，在我们看来，这是非常不同的。

此致

Marcelo Monsores

嗨Reza。

我认为"缓解控制"的命名模式取决于您的缓解策略。

例如，如果每种风险都可以控制，则可以将其命名为 MIT _ ，后跟风险ID 。

如果您有多个，则可以在此模式中添加数字后缀（取决于风险ID的大小）。

此致

Marcelo Monsores