Vendor risk assessment
This assessment can help teams evaluate dependency and continuity considerations when planning a solution using MDriven Turnkey. It is intended to separate what is documented about the platform's security architecture from matters that must be confirmed with the vendor, in contracts, or in the planned deployment.
A useful assessment records the solution's data, users, access rules, client exposure, operational dependencies, and the consequences of changing or losing a component. Assess the planned solution as well as the platform.
Assess documented security characteristics
The supplied MDriven documentation describes an architecture in which a ViewModel defines the information slice shown to an authenticated and authorised user for a use case. It states that ViewModel data reduction occurs on the server and that each ViewModel is implemented with declarative OCL expressions. It also states that access-control rules are defined declaratively in the model and can depend on data in the model.
Use the following questions when assessing the planned solution:
| Area | Assess | Evidence to review |
|---|---|---|
| Business and data impact | Identify the data involved, the users who need it, and the effect of inappropriate disclosure. | Document the information required for each use case and the users who should be authorised to access it. |
| Access control | Confirm how the solution's access rules will be defined and reviewed. | Review the ViewModel and its OCL definition for each use case. Review the model's access-control rules with the people responsible for security and business requirements. |
| Server-side information filtering | Confirm that the intended information subset is reduced on the server rather than relying on client-side filtering. | Verify that each ViewModel exposes only the information needed for its use case. |
| Client exposure | Identify what information and action details are available to the client. | Review each use case accordingly. |
| Authentication and communication | Confirm the authentication approach and protection of communication between user and server. | The documentation states that Turnkey authentication uses OAuth2, with optional social login or OpenID single sign-on, and that multifactor authentication can be made part of the access-control system. It also states that communication uses SSL and that a tunnel may be used for stronger cryptographic needs. |
| Operational dependencies | Identify the systems, infrastructure, processes, and people on which the solution depends. | Maintain a dependency record that links each dependency to the business process it supports. |
Evaluate dependency and lock-in risk
Lock-in risk is the difficulty, cost, or operational impact of changing a platform, deployment arrangement, supplier, or delivery team. Record each material dependency, its owner, its impact, and the evidence available for replacing or recovering it.
The documented ViewModel and declarative access-control approach can provide an inspectable definition of the information subset for a use case. This may help teams review how information is exposed. It does not, by itself, establish rights to source code, data export, migration tooling, support, or operational recovery. Those matters require separate confirmation.
Reduce and review risk
Use the following actions as part of the assessment:
- Keep the business model, ViewModels, OCL expressions, access-control rules, and integration definitions under change control.
- Review access rules whenever a use case changes. The documentation describes server-side ViewModel reduction and declarative rules, but the solution team must still define the appropriate rules for its model.
- Map integrations, infrastructure, and responsible stakeholders to the business processes they support.
- Test the intended access boundary. For example, verify that a user who is not authorised for a category of information cannot obtain it through the client.
- Record assumptions that are not covered by the available technical documentation, including licensing, support, source-code access, data export, recovery, and migration arrangements.
Assessment record
Maintain a record for every material risk containing the dependency, impact, mitigation, owner, evidence, and review date. For example: The purchase-approval ViewModel exposes supplier and stock information; the model owner reviews the ViewModel and OCL definition before release; the security owner tests unauthorised access; procurement records the applicable licensing and support terms.