I would abstract out the 'impact' rating for your users of this rating system. The resulting system needs to be clear, simple, and unambiguous. It also needs to result in an auditable output (something someone else can check).
I have done this by reducing the complexity of analysis to the data and the data systems the feature interacts with. Use your existing data classification and data risk model to define the characteristics of the various data types you have (personal, financial, payment card, health, sensitive, etc.) and define what protections those data should have (encrypted, certain access levels, etc.). You probably already have some level of understanding of the impacts of the various data you have, so just borrow it instead of re-inventing the wheel.
Then you can classify the protection/risk level of the data that the feature touches, either directly or via calls to other features/systems.
The data the feature processes has:
* names or personal identifiers
* payment card data, bank details
* health information
* internal financial information
* internal configuration
* passwords, crypto keys
The feature interacts with:
* Database A
* Database B
* 3rd party service C
* payment processors
* external researchers
The result is simple: the dev checks the characteristics of the data the new feature processes and the systems it interacts with, and your checklist should return the classification of the feature. Auditors/peers just need to review that the data indeed has those data characteristics.
All in all, the resulting system is fast, simple, and easy to understand. What makes it work is all the work done previously in identifying the risks and protections required by certain types of data (either by internal risk ratings, laws, regulations, etc.)
If you do not already have a data classification and data risk understanding, it would actually be simpler to create that first, rather than re-inventing that wheel every time you have a new feature to assess. It would also make it easier to update this rating system when things change, like laws or the risk tolerance of the company (three cheers for abstraction and encapsulation!)
An added bonus to the data characteristics inventory approach: if a regulation changes you have a pre-built inventory of data characteristics, so you know the flow of that data through your systems. It's like an up-to-date, organic data flow diagram.