Necmettin,
The IBMFAC(CSVLLA) resource becomes secured immediately after you perform the TSS ADD command to own/secure it.
For CICS, the CICS region ACID will need permission for accessing this resource (and unlikely that any other users will need it for CICS application access). Keep in mind that the need to access the IBMFAC(CSVLLA) resource is not a resource limited to CICS region processing, so once protected, any other need outside of CICS will need to be accommodated with a permission as well.
Whether or not this immediately affects securing of this resource and user access capabilities on other LPARs depends on whether or not you are sharing your TSS SECFILE with other LPARs, or if you are using CPF to sync the SECFILE across your LPARs. If sharing the SECFILE, or if CPF routes and processes the TSS ADD command on other LPARs, then YES, those other LPARs would be impacted by this change.
In my experience with cases of "1st time ownership of a resource", if I'm not 100% certain of the extent of use, especially in a production environment that is already live and running and where an outage is very likely to be problematic and costly, I always assume and prepare for the worst-case scenario (in other words: assume that protecting the resource without having adequate permissions deployed could/would cause an outage).
To minimize the risk of an outage, consider these ideas:
Perform the TSS ADD and permissions during an off-peak time, preferably in a scheduled outage window that will allow time for your to back-out your changes with minimal system/user impact should that become immediately apparent.
Consider using the ALL record as a temporary safety net and a means to discover access needs. Permitting the IBMFAC(CSVLLA) resource to the ALL record ensures immediate access to the all users without the need to perform a TSS REFRESH. The permission to the ALL record should be performed IMMEDIATELY after you "TSS ADD" the resource to secure it. But even with using the ALL record ... there is a time lapse between the time that the TSS ADD command runs and the TSS PERMIT command to the ALL record ... albeit a short time lapse, possibly even just a second or two ... where a security violation may occur.
The permission in the ALL record will also help to facilitate a discovery process -- to enable you to track, collect, summarize, and monitor access to the resource, so that you know exactly which users need the access, and the access levels that they are requesting/using. You can accommodate this discovery by including the ACTION(AUDIT) keyword on the permission, and then reporting use of this resource over time by running the TSSUTIL report against the audited events over some period of time. Then, you can deploy permissions to other profiles/users as needed, and at some point you can then safely revoke the permission from the ALL record once you determine that you have adequately permitted the resource elsewhere.
In these types of endeavors I've had clients initially express concerns about permitting to the ALL record (it's usually against policy and poor security practice when done indiscriminately), but in the context that it is just temporary, for the purpose of preventing an outage and discovering usage, that has always alleviated those concerns. (Permitting to the ALL record doesn't provide any additional access capabilities to what was already allowed via the not-owned resource, but it adds the benefit of being able to track and discover use).
I hope this information is helpful to you.