A secure enterprise platform has to protect more than sign-in. The relevant safeguards extend across each authenticated user, tenant boundary, API call, workflow approval, document revision and operational event.
Numerish brings specialist applications into a shared operating environment. Security assurance therefore needs to cover platform-wide services as well as the specific add-on and deployment a customer intends to use.
The descriptions below outline control expectations and evidence to evaluate. They do not claim that a specific Numerish product has completed independent certification.
Each domain brings a specific objective and a practical review item. Choose the level of assurance needed for the relevant service and regulatory context.
Examine who can enter a tenant, how identities are authenticated, when recent MFA is demanded for sensitive actions, how roles are scoped and how elevated access is reviewed.
Identity policy, role matrix, MFA policy, recent-session enforcement evidence and privileged-access review records.
Assess organisation boundaries, permission propagation between ERP360 and subscribed add-ons, cross-tenant access checks and how shared integration services enforce the originating principal.
Architecture and data-flow boundaries, isolation tests, API authorisation contracts and negative-access test records.
Review how information is encrypted in transit and at rest, where key material is held, how key rotation and access separation work, and which government/sovereign features are actually commissioned.
Cryptographic architecture, key custody and rotation evidence, TLS configuration, HSM/KMS evidence where included, and exception register.
Determine whether code is reviewed, dependencies assessed, releases verified, vulnerabilities triaged and remediations tracked with a clear owner and audit trail.
Release provenance, SBOM where provided, vulnerability assessment procedures, remediation tickets, independent penetration-test scope.
Understand security telemetry, incident escalation, evidence retention, disaster recovery ownership and the point at which affected customers are notified.
Logging coverage map, incident response runbook, incident exercise evidence and scoped restore-test receipts.
Identify every material third-party integration and API trust boundary. Access must be assessed for consent, scopes, credentials, revocation and data transfer.
Integration inventory, provider responsibility matrix, machine authentication controls and approved subprocessor schedule.
The dividing line between supplier capability and customer responsibilities should be agreed before implementation or procurement sign-off.
Security controls should be accepted against the actual subscribed products, hosting model and evidence supplied—not inferred from product-page descriptions.
Request product- and version-specific artefacts; identify the relevant jurisdiction, data classes, hosting model and procurement requirements.
Controls and independently verified outcomes should not be confused.
Not necessarily. A shared security design does not establish the installed version, rollout state, independent testing or certification of each add-on. Request the version-specific security and acceptance evidence.
No. Government configurations can require dedicated providers, key custody, sovereignty controls and jurisdictional commissioning. Technical architecture alone does not establish regulatory acceptance.