Holding RMiT compliance on one control plane
How a regulated financial institution evidenced the technology operations and cybersecurity requirements of RMiT with DevOpsArk, and kept them true after the audit.
What is RMiT, and what does DevOpsArk do about it?
RMiT is the Risk Management in Technology policy document that Malaysia's central bank imposes on licensed financial institutions. DevOpsArk covers the delivery, operations and security requirements inside it by turning asset inventory, change control, access, availability, patching and vulnerability evidence into a continuously maintained record instead of an annual reconstruction.
What RMiT actually measures
Per critical system, on a rolling twelve months, for anything customers or counterparties expect to be delivered immediately (10.32).
Per incident, for those same critical systems (10.32).
Network device logs (10.42) and user activity logs on critical systems (10.57), retained and reviewed rather than merely stored.
From the issuance date of the policy document to submitting a gap analysis and a dated action plan (18.1).
What RMiT is
Risk Management in Technology is the policy document on technology and cyber risk issued by the central bank of Malaysia for the institutions it supervises. Current version issued 28 November 2025, superseding the 2020 document.
Part A: Overview
Introduction, applicability, legal provisions, effective dates, interpretation and the instruments this document supersedes. Requirements marked S are enforceable standards; those marked G are guidance.
Part B: Policy requirements
Governance (8), Technology Risk Management (9), Technology Operations Management (10), Cybersecurity Management (11), Digital Services (12), Technology Audits (13), External Party Assurance (14) and Security Awareness and Education (15). Section 10 is the longest and the one a delivery platform touches most.
Part C: Regulatory process
Notification for technology-related applications (16), consultation and notification for public cloud and emerging technology (17), and assessment and gap analysis (18).
Eleven appendices
Removable media, self-service terminals, digital services, mobile applications, cybersecurity control measures, simplified notification criteria, risk assessment and external party assurance formats, third party IT risks, emerging technology guidance, cloud services, and fraud detection standards.
- Licensed banks
- Licensed investment banks
- Licensed Islamic banks
- Licensed insurers and professional reinsurers
- Licensed takaful operators and professional retakaful operators
- Prescribed development financial institutions
- Approved issuers of electronic money
- Operators of a designated payment system
- Registered merchant acquirers
- Intermediary remittance institutions
The estate, and what made this hard
| Institution profile, anonymised | Detail |
|---|---|
| Sector | Licensed financial institution with retail and payment channels |
| Supervision | RMiT, plus the operational risk and business continuity policy documents it refers to |
| Estate | Two production data centres and one public cloud region: virtual machines, Kubernetes, managed databases and a small serverless footprint |
| Delivery | Around ninety deployable services across core, channel and integration layers |
| People | One platform team, six product squads, an independent technology risk function and a CISO office |
| Trigger | A revised policy document, a ninety day window for the gap analysis, and a board that wanted the answer before the auditors asked |
The evidence existed, but never in one place
Asset inventory lived in three spreadsheets, change records in the ticket system, access grants in four consoles, and availability in a dashboard nobody had reconciled against the four hour budget. Every question from the risk function became a week of collection work.
The policy is written per control, the estate is organised per team
A paragraph such as 10.17 applies to every host, image, cluster and function at once. Six squads each answered for their own services, so nobody could state the position for the institution without assembling it by hand first.
Rapid delivery is allowed, but only if the review is automated
Paragraph 10.6 permits rapid system development methodology and then requires the IT security compliance review, vulnerability discovery and testing to be automated, because the dynamic environment increases the likelihood of error. Manual gates in a pipeline do not satisfy that.
Availability became a published number
Paragraph 10.31 requires early warning of degradation and intermittent failure, escalation when a disruption reaches five per cent of expected daily customers or transactions, and a quarterly disclosure of the availability track record. That needs per-service measurement, not an aggregate uptime figure.
Three years of logs across a fleet nobody had fully enumerated
Retention under 10.42 and 10.57 is straightforward once you know what is running. The institution did not, so the retention question could not be answered honestly before the inventory question was.
The calendar never stops
A quarterly vulnerability assessment, an annual intelligence-led penetration test, an annual cyber drill, an annual review of cryptographic algorithms, a red team simulation every three years and an external data centre resilience assessment every three years. Each one needs a scope, and the scope is the estate.
RMiT paragraph by paragraph
Each domain states what the policy document asks for, then what the platform actually produces towards it. Where the honest answer is that the requirement is not a platform matter, it is in the exclusions further down rather than dressed up here.
Asset inventory and the technology risk profile
The requirement. A complete and current view of information assets and critical systems, classified by criticality, with interdependencies and third party linkages identified, maintained through a centralised automated tracking system. Shadow IT must be actively identified and reduced.
- Continuous discovery across clouds, clusters, virtual machines, containers, functions and DNS, so the inventory is observed rather than declared.
- Criticality and ownership carried as attributes on every service, which is what turns an inventory into a risk profile.
- Dependency mapping between services, clusters, databases and external endpoints, feeding the single point of failure analysis that 10.4(b) asks for.
- Anything running in a connected account that nobody claims is surfaced as unowned, which is the practical form of shadow IT detection.
- One inventory for the whole estate, not one per environment, so the institution has a single number to report.
Secure delivery and change control
The requirement. An SDLC covering requirement through decommissioning, integrated with architecture, risk and security. Production segregated from development and testing, and in cloud not sharing a virtual host. Source code review before change, independent review and approval of changes, tested contingency plans for material changes, and automated security compliance review where the methodology is rapid.
- Every deployment carries its provenance: commit, reviewer, approver, scanned artifact digest, target environment and the rollback that was available.
- Policy gates run in the pipeline, so an artifact that fails a scan or a baseline check cannot reach production without a recorded exception.
- Independent approval is enforced by the platform rather than by convention: the identity that authors a change cannot be the identity that approves its release.
- Environment separation is modelled explicitly, including the cloud case where development and production must not share a virtual host.
- Progressive rollout with automatic rollback is the tested contingency plan that 10.11 asks for, exercised on every release rather than written once.
- Decommissioning is a tracked lifecycle state, which is what makes 10.13 answerable.
Patch and end-of-life management
The requirement. No system running with a known security vulnerability, on an outdated platform or on end-of-life technology. A current security baseline, continuous monitoring of patch releases, criteria and turnaround times set by severity, compatibility testing before deployment, and management-approved exceptions with a phase-out timeline reviewed at least annually.
- Patch position per host, per cluster, per node image and per container image, in one view, with the severity that sets the deadline.
- End-of-life tracking on operating systems, runtimes, base images and cluster versions, with the date the risk becomes an exception.
- Baseline drift detection, so a hardened configuration that was changed by hand is visible the same day rather than at the next audit.
- Exceptions carry an owner, a justification, a phase-out date and an expiry, and reappear when the date passes.
- Remediation is tracked to closure with the fix that applies, so the reported position and the real position are the same number.
Access control and privileged activity
The requirement. Deny all by default, least privilege on a need-to-have basis, time-bound access, segregation of incompatible functions, defined dual authorisation activities, multi-factor authentication for critical systems and for every remote access session, a periodically reviewed access matrix, and activity logs on critical systems retained for at least three years and reviewed in a timely manner.
- Roles and grants for the whole estate in one matrix, which is the artefact 10.56 asks to be reviewed.
- No standing production access: elevation is time-bound, needs a recorded justification and an approver, and expires without anyone remembering to remove it.
- Incompatible functions enforced as policy, including the development and operations separation named in 10.54(d).
- Dual authorisation on the action classes the institution defines, applied at the point of action rather than in a procedure document.
- Every privileged action, human or agent-initiated, written to one audit trail with the retention class the policy requires.
- Access reviews driven by actual usage, so a grant nobody has used is visible as a grant to remove.
Service availability and resilience
The requirement. Planned capacity, real-time monitoring of capacity and performance with actionable alerts, early signals of degradation and intermittent failure, escalation when a disruption affects five per cent or more of expected daily customers or transaction volumes, cumulative unplanned downtime of no more than four hours on a rolling twelve months with a maximum tolerable downtime of 120 minutes per incident, network bandwidth monitoring with anomaly detection, and backups whose restoration is tested with a tamper-proof copy and an isolated recovery environment.
- Availability measured per digital service and per delivery channel against the four hour and 120 minute budgets, with the remaining allowance shown as a number rather than a percentage.
- Degradation detection on latency, error rate and failed transaction volume, which is what turns 10.31(a) from an aspiration into an alert.
- Customer and transaction impact estimated during a disruption, so the five per cent escalation threshold has something to fire on.
- Alerting that routes on ownership and suppresses the duplicates, because an escalation path only works if the first page is the right one.
- Backup coverage and, more importantly, restore test results per backup set, which is the part of 10.44 that usually has no evidence.
- Dependency and single point of failure analysis maintained continuously, feeding the periodic interdependency review in 10.31(b).
Cryptography, keys and certificates
The requirement. A cryptography policy covering algorithms, key lifecycle and compromise recovery. An IT asset inventory extended to every cryptographic tool and algorithm in use, mapped to the applications it supports. An annual review of the algorithms on critical, externally linked and customer-facing systems. Institution-held keys for anything carrying customer information.
- Certificate inventory across load balancers, ingress, service mesh and endpoints, with expiry, issuer and renewal history.
- Renewal before expiry as the default behaviour, because an expired certificate on a customer-facing channel is an availability incident and a control failure at the same time.
- Algorithm and protocol versions collected as inventory attributes, which is what makes the annual review in 10.20(c) a report rather than a project.
- Weak protocol and cipher detection on external endpoints, tracked with the rest of the vulnerability backlog.
- Secret material referenced from the key store the institution already owns, so 10.21(a) ownership of keys is never in question.
Cybersecurity operations and vulnerability assessment
The requirement. Continuous and proactive monitoring across all critical systems and their supporting infrastructure, log collection with an event correlation engine, vulnerability management, threat hunting, forensic capability, a 24x7 security operations centre with an end-to-end view of the infrastructure, a quarterly vulnerability assessment of internal and external components supporting critical systems, an annual intelligence-led penetration test and a red team simulation at least once every three years.
- Posture evaluated continuously against the institution's baseline, with each finding carrying the paragraph it affects.
- Log collection with structure and retention classes, forwarded to the existing SIEM rather than competing with it.
- Image, code, dependency, infrastructure-as-code and secret scanning on every build, which is the continuous half of the quarterly assessment cycle.
- One vulnerability backlog with ownership, severity and deadline, so findings from a scanner, a penetration test and a red team exercise are tracked the same way.
- Anomaly detection on behaviour rather than hand-written thresholds, for the signature-less activity Appendix 5 Part C names.
- Log analysis that narrows an incident to the relevant lines, which is where most of an investigation timeline actually goes.
Technology audit, gap analysis and reporting
The requirement. An annually reviewed technology audit plan with appropriate coverage of critical technology services, third party service providers, material external interfaces, terminated projects and post-implementation reviews. A gap analysis against the policy document with an action plan carrying clear timelines and milestones, submitted within ninety days of issuance, and an updated annual self-assessment available to the regulator on request.
- Each control domain reported as a current position with the evidence behind it, so the self-assessment is a read rather than a rebuild.
- The action plan tracked as work with owners and dates, against the same inventory the gap analysis was written from.
- Post-implementation review inputs available per release: what changed, what it touched, what it broke and how long recovery took.
- Trend rather than snapshot, which is what tells the board whether a control is improving or quietly decaying.
- Plain questions answered against the institution's own estate, so an auditor request does not become an engineering task.
Where DevOpsArk itself sits in the assessment
A platform that reads a regulated estate becomes part of that estate's third party risk. These are the answers your risk function will ask for, given plainly.
RMiT binds the institution, not the vendor
No platform can be RMiT certified, and any vendor claiming to be is describing something that does not exist. What a platform can do is avoid creating a gap, and produce the evidence the institution needs for its own third party assessment under paragraphs 10.46 to 10.52 and appendices 7, 8 and 10. That is the claim DevOpsArk makes and the only one worth making.
Read-only by default, revocable without us
Inventory, monitoring, posture and cost work on read-only credentials. Write access is a separate grant, scoped per system, per namespace and per action type. Because the credential is a role or a service account in the institution's own directory, deleting it ends platform access immediately, with no ticket and no vendor involvement. That is a property of the architecture, not a policy commitment.
Application data stays inside the governance boundary
DevOpsArk holds operational telemetry: inventory, configuration, metrics, deployment history, access records and the logs you choose to route. Data in your databases, volumes and object storage is not read. Managed clusters provisioned through DMK8S run in the institution's own cloud account, which keeps workloads and customer data where paragraph 10.52 and Appendix 10 require them to stay.
Keys and secrets stay with the institution
Paragraph 10.21(a) requires the institution to retain ownership and control of encryption keys for anything carrying customer information. DevOpsArk references material from the key and secret stores the institution already operates rather than becoming a second custodian, and platform-held customer credentials sit in a dedicated store with separate access control and a full read audit.
Segregation of duties is enforced rather than assumed
Paragraphs 10.7, 10.11 and 10.28 all turn on the same idea: the person who makes a change is not the person who approves it, and the environment where it is built is not the environment where it runs. Both are modelled in the platform, including vendor and contractor access to production, which 10.28 requires to be authorised and monitored specifically.
The paperwork a notification needs
For a consultation or notification under section 17, or an assurance exercise under Appendix 7, DevOpsArk supplies architecture and data flow descriptions, a control description mapped to paragraph numbers, region of processing and residency, subprocessor detail, and SOC 2 Type II and ISO 27001 reports under NDA. The institution's risk assessment report and the CISO confirmation remain the institution's own documents to write and sign.
Twelve weeks from read-only access to a reportable position
Nothing in the first fortnight changes anything in the estate. That matters in a regulated environment: the platform earns write access after it has proved the inventory is right.
- 1Weeks 1 to 2: connect read-only and build the inventory
Create scoped read-only credentials in your own clouds, clusters and repositories. Discovery populates the asset and service inventory, including the accounts and workloads nobody expected to find. Nothing is installed in your clusters. No change is made to anything.
- 2Weeks 2 to 4: map the policy to the estate
Work through Part B paragraph by paragraph against the real inventory rather than against an architecture diagram. Each requirement lands in one of three buckets: evidenced today, evidenced once configuration changes, or outside the platform. The third bucket is the honest one, and it goes to the risk function rather than into a product roadmap.
- 3Weeks 4 to 8: close the delivery side
Bring builds and deployments onto pipelines with scanning, policy gates, independent approval and recorded provenance. Model environment separation, including the cloud virtual host constraint in 10.7. Turn on progressive rollout so the contingency plan in 10.11 is exercised on every release.
- 4Weeks 6 to 10: close the operations side
Set availability budgets per digital service against the four hour and 120 minute limits. Configure degradation detection and the five per cent escalation threshold. Put log retention classes in place for the three year requirements, schedule restore tests, and reconcile the access matrix with what is actually granted.
- 5Weeks 8 to 12: turn evidence into reporting
Assemble the recurring outputs: the board pack, the monthly threat assessment inputs, the vulnerability position by severity and owner, the availability record for quarterly disclosure, and the gap analysis and action plan in the form section 18 expects.
- 6Week 12 onward: hold the line
Compliance decays quietly. Drift detection, continuous posture evaluation, expiring exceptions and usage-driven access reviews exist so that the position you reported and the position you are in do not separate over the following eleven months.
The compliance calendar, and who keeps it
Compliance is not an event. These are the recurring obligations a delivery and operations platform can carry, and what it contributes to each.
| Cadence | What the policy requires | What DevOpsArk contributes |
|---|---|---|
| Continuously | Accurate asset inventory and risk profile (9.2(h), 11.3(h)); proactive monitoring of security posture (11.9); real-time capacity and performance monitoring (10.30). | Discovery, posture evaluation, drift detection, anomaly detection and availability measurement run without being scheduled. |
| On every change | Source code review, independent approval, compatibility testing, automated security compliance review and a tested fallback (10.6, 10.10, 10.11, 10.18(c)). | Pipeline gates, scanning, approval enforcement and progressive rollout with automatic rollback, recorded per deployment. |
| Daily | Timely detection and resolution of service interruption (10.30); timely investigation of flagged anomalies (10.57(b), 11.11). | Alert routing by ownership, incident timelines assembled from telemetry, and log analysis that narrows the search. |
| Monthly | Security operations centre threat assessment report covering trends, statistics and emerging threats (Appendix 5 Part C). | Findings, incidents and vulnerability movement exported by category, severity and system criticality. |
| Quarterly | Vulnerability assessment of internal and external network components supporting critical systems (Appendix 5 Part D); disclosure of the service availability track record within fifteen calendar days of quarter end, from 15 October 2027 (10.35(e)). | Scan coverage and results by asset class, and the per-service availability and degradation record the disclosure is built from. |
| Annually | Intelligence-led penetration test and cyber drill (Appendix 5 Part D, 11.16); review of cryptographic algorithms in use (10.20(c)); review of end-of-life exceptions (10.17(d)); technology audit plan review (13.2); self-assessment of compliance (18.1). | Scope drawn from the live inventory, findings tracked to closure in one backlog, and the exception register raising anything whose date has passed. |
| Every three years | Red team simulation on the infrastructure (11.6); production data centre resilience and risk assessment by a competent external party (14.1). | Inventory, dependency maps and architecture description for scoping, and a single backlog to hold the findings afterwards. |
| Rolling three years | Retention of network device logs (10.42) and of user activity logs on critical systems (10.57(c)), reviewed rather than only stored. | Retention classes per log stream, with audit classes retained separately from operational telemetry. |
The artefacts an auditor asks for
| Artefact | Produced by | References |
|---|---|---|
| Asset and service inventory with criticality, ownership and dependencies | ArkApps, Servers, Kubernetes, CaaS, FaaS | 9.2(d), 9.2(i), 11.3(b), 11.3(h) |
| Change record per deployment: commit, reviewer, approver, artifact digest, environment, rollback | Pipelines, ArkCD, Release Management | 10.5, 10.10, 10.11, 10.14 |
| Scan results per artifact with severity, owner and fix status | Scanners, Vulnerability Management | 10.6, 10.15(a), Appendix 5 Part D |
| Patch and end-of-life position per host, cluster, node image and container image | Servers, Kubernetes, Vulnerability Management | 10.17, 10.18 |
| Access matrix, elevation records and privileged action audit trail | IAM, Secrets | 10.54, 10.56, 10.57 |
| Availability and degradation record per digital service against the four hour budget | Monitoring, Observability, 360 DITE | 10.30, 10.31, 10.32, 10.35 |
| Restore test results per backup set, with failures and their root cause | Backups | 10.44(e) |
| Certificate and algorithm inventory with expiry and renewal history | SSL Management, Secrets | 10.20(c), 10.20(d), 10.23 |
| Retained activity, network and application logs by retention class | Log Management | 10.42, 10.57(c) |
| Exception register with justification, approver, phase-out date and review date | Security, Vulnerability Management | 10.17(d), 12.2 |
What DevOpsArk does not do for you
A compliance claim is only worth reading if it says where it stops. These requirements are real, they are yours, and no platform closes them.
- Board and senior management oversight, the technology risk management framework and the cyber resilience framework are documents the institution owns (sections 8 and 9). DevOpsArk supplies the technical facts they depend on, not the frameworks themselves.
- The CISO designation, its independence from day-to-day technology operations, and the certification and competency requirements are organisational matters (9.4, 9.5, 13.3).
- Physical data centre security, redundant power and thermal management, and the external resilience assessment sit outside any software platform (10.24 to 10.28, 14.1).
- Submissions to the regulator are made by the institution: the notifications under section 16, the cloud and emerging technology consultation under section 17, and the gap analysis and self-assessment under section 18.
- Independent external assurance and the CISO confirmation required by Appendix 7 must come from parties independent of the platform being assessed.
- Penetration tests, red team simulations and the annual cyber drill are exercises the institution commissions. DevOpsArk scopes them from the inventory and holds the findings afterwards; it does not perform them.
- Channel-specific controls stay with the applications: fraud detection standards in Appendix 11, self-service terminal controls in Appendix 2, digital service and mobile application controls in appendices 3 and 4.
- Cyber incident notification to the regulator follows the operational risk reporting and business continuity policy documents referenced by 11.18, on the institution's timeline and letterhead.
- Data loss prevention across data in use, in motion and at rest (Appendix 5 Part B) needs dedicated tooling at the application and endpoint layer. DevOpsArk covers the infrastructure and delivery side of it, not the endpoint side.
The difference this made
One inventory instead of six
The asset question stopped being a reconciliation exercise. Because criticality and ownership sit on the same record as the technical facts, the risk profile and the inventory are the same artefact rather than two documents that disagree.
The gap analysis became a query
The first gap analysis took weeks, largely spent finding things. The annual self-assessment that 18.1 asks for is now read from the current position, which is why the second one took days rather than another quarter.
Availability stopped being an argument
A measured per-service record against the four hour and 120 minute limits replaced a monthly uptime percentage. Disagreements about whether an event counted moved from opinion to the timeline that recorded it.
Rapid delivery survived the policy
Squads kept deploying frequently because the security compliance review that 10.6 demands is automated in the pipeline rather than performed by a committee. The control got stronger and the lead time did not get longer.
Exceptions acquired expiry dates
End-of-life exceptions used to be approved once and inherited forever. Each one now carries a phase-out date and comes back when the date passes, which is precisely what 10.17(d) asks for and the easiest control to lose quietly.
Audit preparation stopped being a project
Evidence for change, access, patching and availability is produced as a by-product of doing the work. The internal audit function samples the record instead of asking teams to reconstruct it, which is also the only version anyone should trust.
The modules this work runs on
Security
Posture, policy and continuous verification
IAM
Access, roles and approvals
Vulnerability Management
From finding to fix, with ownership
Pipelines
CI/CD pipelines with policy and provenance
Log Management
Centralised logs with structure and retention
Monitoring
Infrastructure and application monitoring
Servers
Fleet inventory, patching and access
Backups
Backups with restores that are actually tested
RMiT: frequently asked questions
RMiT places obligations on licensed financial institutions, not on software vendors, so no platform can be RMiT certified. The useful questions are whether a platform creates a gap and whether it produces the evidence your third party assessment needs. DevOpsArk is built for both: read-only by default, revocable from your side, no application data, and a control description mapped to paragraph numbers.
Most of section 10 on technology operations management, the monitoring and vulnerability parts of section 11 and Appendix 5, and the evidence that sections 13 and 18 need for audit and self-assessment. Governance in section 8, the frameworks in section 9, physical data centre controls, external assurance and the regulator submissions stay with the institution.
That depends on your deployment and your existing filings. Section 17 requires a consultation before first-time adoption of public cloud or emerging technology for critical systems, and a notification for subsequent adoptions, and section 16 covers new or materially enhanced digital services. If DevOpsArk is part of such a change, it belongs in that assessment, and we supply the architecture, data flow and control detail the risk assessment report needs.
By making the estate knowable in the first fortnight. A gap analysis is mostly discovery work: what is running, who owns it, what is patched, who has access and what changed. With that inventory in place, the exercise becomes reading a position per paragraph and writing an action plan, rather than assembling facts from six teams and three spreadsheets.
Yes. Inventory, monitoring, posture, availability measurement, patch position, access review and cost attribution all work on read-only credentials. Write access is a separate grant needed only for deployment, provisioning and remediation, scoped per system, per namespace and per action type. Many regulated institutions begin read-only and stay that way for months.
Per critical system and per digital service, from the customer-facing interface rather than from host uptime, and on a rolling twelve months as 10.32 specifies. Each incident is recorded with its start, its recovery and whether it breached the 120 minute per-incident limit, and the remaining allowance for the year is shown as time rather than as a percentage.
For the streams you route to it, yes: retention classes are configured per stream, and audit classes are retained separately from operational telemetry so a cost decision on metrics cannot quietly shorten an audit trail. Network device logs under 10.42 usually stay in your existing collector, and DevOpsArk complements that rather than replacing it.
No, and you should not. Appendix 5 Part C requires a 24x7 security operations centre with correlation, threat hunting and forensic capability, which is an operating function rather than a product. DevOpsArk feeds it: structured logs, posture findings, anomaly signals and a single vulnerability backlog with ownership and deadlines.
No. Paragraph 10.21(a) requires the institution to retain ownership and control of keys protecting customer information, so DevOpsArk references your existing key and secret stores rather than becoming a second custodian. Credentials you issue to the platform are held in a dedicated store with separate access control and a read audit, and you can delete them at any time.
Environment separation is part of the deployment model rather than a naming convention, so production, staging and development targets are distinct and the platform will not promote an artifact across them without the recorded approval. Where the estate is in cloud, node pools and placement are modelled, which is what makes the second sentence of 10.7 answerable with evidence.
The control structure is. Asset inventory, change control, segregation of duties, patch and end-of-life management, access control, availability measurement, log retention and vulnerability management appear with different paragraph numbers in most technology risk regimes. The mapping changes; the evidence a platform has to produce does not.
Working through RMiT right now?
Bring your gap analysis and we will tell you which paragraphs the platform evidences, which need configuration, and which are not ours to close.