SaaS Security Inline ' s risk-score customization capability exists specifically so an organization ' s own sanctioning decisions can be reflected in the numeric risk value that downstream Security policy rules evaluate, rather than relying purely on the platform ' s generic, vendor-assigned default risk ratings, which may not align with a specific organization ' s governance decisions about which applications are approved. By deliberately lowering the risk score assigned to applications the organization has sanctioned and raising the risk score assigned to applications it considers unsanctioned, an administrator can then build a single, risk-threshold-based Security policy rule (for example, blocking any SaaS traffic above a defined risk score) that automatically and consistently restricts unsanctioned application usage without needing to individually enumerate every unsanctioned application by name — a much more maintainable, scalable control as the SaaS application landscape grows. This makes option A the intended, documented use of the risk-customization feature. Uniformly increasing the risk score for all SaaS applications (option B) would defeat the purpose of differentiated governance entirely, since it would fail to distinguish sanctioned from unsanctioned traffic and could block legitimate business applications alongside unwanted ones. Options C and D both describe building an application filter based on an " unsanctioned SaaS " category or characteristic, which is a legitimate alternative policy construction technique in its own right, but it is a distinct mechanism from risk score customization — the question specifically asks how risk score customization is used, and neither C nor D actually involves adjusting risk scores at all.