Una obligación que está en papel todavía no es una obligación cumplida. Entre «tenemos una política» y «demostramos que tenemos el control» hay una capa que a menudo se pasa por alto: la prueba. Y no todo documento que se guarda en algún lugar cuenta como prueba.
Un documento de política describe una intención. Dice lo que una organización quiere hacer, no lo que ha ocurrido. Un auditor o un supervisor no pregunta por la política, sino por su resultado: si la evaluación de riesgos se ha realizado efectivamente, si la aprobación se ha registrado, si la desviación se comunicó en el momento en que se produjo. Cómo se hace demostrable ese paso de la política a la práctica depende del tipo de obligación y de la forma en que se ha diseñado un proceso; cómo demuestra que la política también es práctica profundiza en esa distinción.
Una prueba es un rastro que registra una acción, una decisión o un control en el momento en que tuvo lugar, con una fecha, un nombre y un resultado. Un correo electrónico en el que se ha comunicado un riesgo. Una línea de acta en la que un consejo ha hecho una valoración. Un archivo de registro que muestra que un control se ha ejecutado realmente, no solo que estaba planificado. Una declaración firmada por un proveedor. La característica común: se puede reconstruir a posteriori quién hizo qué y cuándo, sin que nadie tenga que volver a contarlo.
Que algo cuente como prueba depende en gran medida de la obligación a la que se refiere. Una obligación de información exige un tipo de rastro distinto al de un deber de diligencia, y un deber de diligencia exige, a su vez, algo diferente a una obligación de notificación. No existe una lista fija que dé la misma respuesta para cada obligación; lo que cuenta se deriva de la naturaleza de la propia obligación y de lo que un supervisor haya establecido al respecto.
En la práctica, la prueba rara vez surge en un solo lugar. Una evaluación de riesgos está en una hoja de cálculo de la primera línea. La aprobación está en un intercambio de correos con un responsable. El control final está en un sistema de un tercero. Cuando hay que demostrar una obligación, alguien debe volver a reunir estos tres rastros, y eso no siempre se consigue. A medida que una organización crece, tiene más departamentos o trabaja con más partes externas, aumenta la probabilidad de que la prueba se encuentre en un lugar que ya nadie conoce. dónde se dispersa la prueba describe los patrones que se dan con más frecuencia en este proceso: traspasos entre departamentos, cambios de sistema y procesos encomendados a un tercero.
Una prueba que no es localizable para nadie más que quien la elaboró no funciona como prueba. Un auditor, un nuevo responsable de cumplimiento o un supervisor debe poder seguir un rastro sin que la persona que lo redactó originalmente esté al lado para explicarlo. Eso impone exigencias sobre dónde se conserva la prueba y cómo se etiqueta: vinculada a la obligación a la que se refiere, con una fecha y un responsable, en un lugar que no dependa de una única persona que, por casualidad, todavía siga en la organización. cómo conservar la prueba para que un auditor la encuentre profundiza en esa organización.
Cada elemento de prueba pertenece a una obligación, y cada obligación pertenece a alguien que puede explicar por qué la prueba es suficiente. Sin ese vínculo, se forma un archivo de documentos del que ya nadie sabe qué obligación debían demostrar, ni quién era responsable de su calidad. quién es el propietario de una obligación describe por qué esa asignación no es una formalidad, sino el eslabón que hace útil la prueba en el momento en que se solicita.
Los cuatro elementos —obligación, propietario, prueba, control— deben figurar juntos en un único panorama, no repartidos entre departamentos y sistemas. Ese panorama tiene un nombre: una matriz de control. Lo que contiene exactamente esa matriz y cómo se construye se describe en qué es una matriz de control. En un grupo con varias entidades o sedes en distintos países, esta cuestión se vuelve más compleja, porque una prueba válida en un nivel no lo es automáticamente en otro; qué cuenta como prueba de una obligación en un grupo con varias entidades aborda específicamente esa situación.
Esta página describe qué es la prueba y dónde se produce el error, no qué prueba concreta es suficiente para su organización. Eso depende de la obligación, del sector y del país en el que esté establecida una entidad, así como de la forma en que los legisladores nacionales hayan concretado una norma europea. csrdcompliance.net señala esa diferencia, pero no sustituye el asesoramiento jurídico y no ofrece ninguna garantía sobre el resultado ante un supervisor.
Mapear y poner en orden la prueba requiere trabajo: reunir rastros, vincularlos a una obligación, etiquetarlos para que otra persona los pueda encontrar. Parte de ese trabajo es repetitivo y sigue un patrón fijo, lo que lo hace apto para (parcialmente) automatizar. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte de ese trabajo puede asumir la IA, de modo que quede claro dónde sigue siendo necesaria una persona para la evaluación y dónde se puede apoyar la recopilación y el ordenamiento de la prueba. El Compliance Check de csrdcompliance.net está en construcción; quien desee recibir noticias al respecto puede inscribirse en la lista de espera.
Vraag maar welke verplichting op u van toepassing is, en waaraan u dat kunt aantonen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.